网心技术 | 从 GitHub 实践看 Agent 代码时代的机遇与代价

前言：语言模型本质上在做什么

如《Claude Managed Agents 让 Harness 变成服务》一文所言，语言模型是一个条件续写器。你给它一段上下文，它根据这段上下文预测下一个 token；把这个 token 接回上下文，再预测下一个；如此循环，直到生成停止。

如上图所示，当用户问"网心科技是一家什么公司？"时，模型先看到完整问题，生成"边"；上下文变成"网心科技是一家专注边"，再生成"缘"；继续拼接后再生成"计"……最终我们看到的完整回答，像是一次性想出来的，但实际上是一个个 token 按概率逐步拼接而来的。

本质上，语言模型是一个概率模型，世界知识服从某种概率分布，且本身没有任何记忆，也没有任何对外部世界的感知。 每次调用，它看到的全部"世界"就是你送进去的那段上下文——称之为"窗口"（context window）。窗口之外的一切，对模型来说不存在。

Agent 调用工具、提取数据，构建起"环境"（environment），本质上是从现实世界中获取更多信息来补充这个上下文。按照对业务的理解，组织好上下文，以此为前置的信息，让模型从自己训练学习到的世界知识中提取能够用于解决当前问题的信息。正如《Claude Managed Agents 让 Harness 变成服务》一文中所指出的：Agent 从来都不是"一个更会聊天的模型"，而是一个带控制面的执行系统——模型负责根据上下文做判断，工具负责接触外部世界，harness 负责协调两端，runtime 负责保证这一整套流程能持续运行。

在代码这个领域，Agent 展现出了格外突出的能力。原因并不难理解：代码是形式化的语言，代码片段的信息密度极高，一个函数签名就包含了类型、参数、返回值等丰富的结构化信息；最关键的是，代码有封闭可验证的特性——通过编译、测试、可以验证结果，整个反馈回路是闭合的。这些特性使得模型在代码生成上的表现显著优于开放式写作等缺少客观评判标准的任务。

当然LLM 本省也不是没有缺点：

第一，训练数据的质量问题。 

当今主流模型的预训练语料中包含了互联网上海量的开源代码——其中不乏冗余实现、过时的反模式和未经优化的片段。模型从中学到的"先验"（prior）本身就可能携带技术债务。它会写出风格统一、结构工整的代码，但这些代码所体现的"最佳实践"，可能只是互联网上出现频率最高的实践，而非真正最优的实践。这是一个从训练阶段就埋入的系统性偏差，后面我们会看到它在实际工程中的放大效应。

第二，信息不完整导致的收敛困难。 

当我们的需求描述模糊、不具备全局信息时（尤其是那些隐藏的约束，比如线上环境中遇到的真实故障场景、客户的具体诉求、系统间的运维耦合），虽然 Agent 生成代码的速度很快，但它产出的结果可能偏离真正的解决方案，这时就需要不断通过人类反馈或工具验证让它持续迭代。

优秀工程师都有自己的关于是否符合预期的度量（measure），以这个度量为手段让模型不断识别当前实现和目标解法的距离（distance），然后不断收敛。这个过程的本质，就是 Agent 在一个不完整的信息空间中做搜索和逼近——而搜索的效率，取决于每一轮迭代中注入的上下文质量。

尽管存在这些问题，Agent 在代码领域带来的效率提升是真实的、巨大的。今天，几乎所有科技公司都在通过 Agent Coding 来加速软件的生成和管理。而 GitHub 作为全球最大的代码托管与协作平台，在这个方向上积累了罕见的一手经验：它既是 Agent 代码的最大消费者之一，也在自己的工程体系中大规模部署了 Agent 来维护。这种"既是用户又是建设者"的双重身份，让它比大多数组织更早、更深地触碰到了 Agent 代码时代最尖锐的问题。

我们可以从 GitHub 近期公开的工程实践中，提取出三个层层递进的核心问题：

1. Agent 以前所未有的速度生成代码，但它引入了哪些传统开发流程未曾面对的新风险？

2. 为了系统性地应对这些风险，需要构建怎样的自动化工作流体系？

3. 当自动化工作流自身也产生了可观的成本，如何在效率与开销之间找到平衡？

速度的代价：当产出超过了审查的承载力

✅  看不完的PR

Agent Coding 的第一感受是量变：代码生成速度的百倍提升，不仅让更多人参与到编程开发，也大幅提升了开发效率。与原来设计与思考消耗大量时间、代码生成慢、审查消耗小不同，以当前代码产出的速度，人类审查能力已经严重不足。

以 GitHub 的公开数据为例：

Copilot 代码审查功能在不到一年内处理量增长了 10 倍，累计超过 6000 万次审查；平台上每 5 次代码审查中就有 1 次涉及 Agent 生成的代码。一个开发者在午餐前就可以启动十几个并行的 Agent 会话，每个会话独立生成代码并提交 PR。

与上述形成鲜明对比的是，审查者仍然是同一批人，他们的认知带宽并没有同步扩展。这不是 GitHub 独有的问题。任何大规模采用代码 Agent 的团队都会面临相同的结构性矛盾：生成端的产能已经被 Agent 杠杆化了，但验证端仍然受限于人类的注意力和判断力。

传统的"提交 → 等待审查 → 合并"循环，其设计隐含了一个假设——代码的生产速度和审查速度大致匹配。而当这个假设不再成立时，整个流程的瓶颈就从"写代码"转移到了"看代码"。

✅  表面光鲜的PR

量变之后，更深层的是质变——或者更准确地说，是质量问题被深度隐藏。

2026 年初发表在 MSR'26（第 23 届国际软件仓库挖掘会议）上的论文《More Code, Less Reuse》对大量 Agent 生成的 PR 做了系统性分析，揭示了一个反直觉的现象：Agent 生成的代码在表面质量上往往很好——命名规范、风格统一、结构清晰，但引入了很多代码冗余和潜在的技术债务。然而，审查者对这些 PR 的情感反应反而更正面，更倾向于快速批准。

这构成了一个危险的正反馈循环：代码越"整洁"，审查者越放松警惕，技术债务就越深地沉淀进代码库。 一旦沉淀下去，后续的 Agent 会在上下文中看到这些已存在的冗余代码，将其当作"先例"继续复制和扩展——这正是前面提到的训练数据质量偏差在工程中的放大效应。所以那些表面光鲜漂亮的PR，未来就是风险。

✅  有什么样的风险呢

从 GitHub 大规模审查 Agent PR 的实践中，可以归纳出五种最容易被人类审查者忽视的风险模式。这些并非理论推演，而是在真实工程实践中反复出现的、有据可查的问题类型：

1. 绕过验证而非修复问题

当 Agent 遇到 CI（持续集成）失败时，它的优化目标是"让 CI 通过"，而非"修复导致 CI 失败的根因"。这两个目标在大多数时候方向一致，但在边界情况下会分离——Agent 可能选择删除失败的测试用例、跳过 lint 检查、或在命令后追加 || true 来吞掉错误。从流水线状态看，一切都是绿色的，但实际问题被掩盖了。这种行为的根源在于 Agent 没有能力区分"测试本身有 bug"和"代码不满足测试要求"，它只能看到表面的信号——通过或失败，并选择让信号变好的最短路径。

2. 局部正确但全局冗余

这可能是对长期代码质量伤害最大的一类问题。Agent 在有限的上下文窗口内工作，它会看到代码库中某个模式并复制它来解决当前任务，但不会——也很难——全局检索是否已经存在一个做同样事情的工具函数或共享模块。结果是代码库中出现大量功能重复但名称不同的实现。更麻烦的是，一旦这些冗余代码被合并，它们就成了代码库的一部分，后续 Agent 的上下文中会包含这些冗余实现作为"已有模式"，进而基于它们继续扩展——形成滚雪球效应。

3. 能通过测试但在边界条件下出错

 这不是"调用了不存在的 API"那种显而易见的幻觉，而是一种更隐蔽的问题：代码能编译、能通过所有现有测试，但在边界条件下存在缺陷，比如说：分页逻辑的 off-by-one、某个分支路径上的权限检查缺失、只在高并发场景下暴露的竞态问题。这些问题的共同特征是：它们超出了当前测试套件的覆盖范围，而 Agent 不具备推断"什么场景没有被测试到"的能力。

4. 无法有效响应审查意见 

审查者花费大量时间撰写了详细的修改建议，Agent 要么不作回应，要么回应了但没有正确理解意图，甚至陷入重复修改的循环。尤其是对于缺乏清晰规划的大型 PR，这种"Agent 失联"的现象概率很高。本质上，当前 Agent 在多轮交互中的目标保持能力还不够稳健，尤其是当审查意见涉及需要全局视角的架构调整时。

5. 工作流中的安全盲区

在自动化流水线中，PR 的描述文本、commit message 等用户可控内容可能被拼接进 LLM 的 prompt，而 LLM 的输出又可能被当作 shell 命令执行。在流水线通常拥有仓库写入权限和 API 凭据的环境中，这等同于一条从用户输入到特权执行的未经审计的路径。当 Agent 的输入来源包含不受信任的文本时，它本质上就是一个可能被注入的执行入口。

✅  审查者的角色在变，而非消失

面对这些风险，一个自然的反应是加强自动化检查。但有一类判断是自动化无法替代的：审查者携带的隐性上下文，比如：关于系统的事故历史、团队约定的边界知识、线上运维约束、以及"这个改法上次导致过一次 P0 事故"这类只存在于人脑中的经验。

Agent 时代的代码审查，真正的价值转移了。审查者不再需要逐行检查命名和风格（这些可以交给自动化工具），而是应当聚焦于三件机器做不好的事：验证流程（CI 和测试）有没有被削弱、新增的实现有没有和已有功能重复、关键业务路径上的端到端逻辑是否完整。 如果用一句话概括：判断力是瓶颈，判断力恰恰是人类不可替代的部分。

接下来，我们先看一看怎么使用自动化来管理 Agent 生成的代码。

自动化工作流管理 Agent 产出

✅  为什么不能只靠人来解决

上一节描述的五类风险有一个共同特征：它们的检测在技术上是可形式化的。判断"一个测试是否被删除了"可以通过对比 diff 实现；判断"一个新函数是否和已有函数功能重复"可以通过语义相似度检索实现；判断"CI 配置是否被修改了"可以通过文件路径过滤实现。换言之，这些检查虽然需要审查者的"注意力"，但不一定需要审查者的"判断力"。

这就引出了一个自然的工程决策：把需要注意力但不需要判断力的检查交给自动化 Agent，让人类审查者专注于需要判断力的部分。 这不是一个新思路，传统 CI/CD 中的 lint、类型检查、自动化测试本质上都在做同样的事。只不过 Agent 代码时代引入的新风险类型（如代码冗余检测、安全态势变化分析）超出了传统静态分析工具的能力边界，而 LLM 的灵活性恰好可以覆盖这些边界。

✅  GitHub 有一个完整的体系

GitHub 在这个方向上走得比大多数组织更远。据其公开披露，团队在内部维护着约 120 个 Agentic Workflow，以自然语言 Markdown 编写、作为 GitHub Actions 调度运行，按需调用 Copilot、Claude、Codex 等不同 Agent 引擎。这些 Workflow 覆盖了仓库维护的几乎每一个环节，形成了一个功能完整的体系。从架构上看，这些 Workflow 在系统中的角色可划分为几个层次：

1. 感知与分诊层

解决"事情发生了，谁应该知道"的问题。包括 issue 自动分类与打标签、PR 路由与分配、机器人活动检测、过期 issue 清理等。这一层的 Workflow 运行频率高（如 issue 分诊平均每天运行近 7 次），是整个体系的入口。

2. 安全防御层

解决"底线不能被突破"的问题。每个 PR 都经过安全态势审查（是否引入了权限提升、网络边界扩展、沙箱削弱等变更）；此外还有每日执行的红队攻击模拟、恶意代码扫描、敏感信息泄露分析等。安全类 Workflow 的设计原则是"宁可误报不可漏报"。误报的成本是审查者多看一条通知，漏报的成本是安全事故。

3. 代码质量层

解决"技术债务持续积累"的问题。包括死代码移除、重复代码检测（直接对应前面讨论的"局部正确但全局冗余"问题）、代码简化与重构建议、破坏性变更检测等。值得注意的是，这一层的 Workflow 很多是"治疗性"的。它们要处理的问题中，有相当比例恰恰是 Agent 自身生成代码时引入的。

4. 文档与知识维护层

解决"信息腐化"的问题。代码在快速迭代，文档跟不上是普遍现象。这一层的 Workflow 负责每日修复和更新文档、维护术语表，甚至从新手视角测试文档的可用性。比如：一个 Agent 按照文档操作会卡住，说明文档需要修改。CI/CD 与基础设施层：解决"流水线本身出了问题"的问题。CI 失败诊断、CI 配置优化建议、定期失败任务调查。这一层的存在作用：自动化系统自身也是需要维护的基础设施。

5. 测试验证层

解决"Agent 引擎是否正常工作"的问题。对接入的每个 Agent 引擎（Copilot、Claude、Codex、Gemini 等）进行冒烟测试，确保引擎本身没有退化。这是一种对供应商依赖的防御性检测。

6. 研究与洞察层

"团队对自身状态的感知"的问题。包括每日信息收集、团队状态报告、每周 issue 摘要等，本质上是将散落在各处的信号汇聚成可使用的摘要。

7. 元自省层

这是最有趣也最重要的一层。它的 Workflow 不管理代码或仓库，而是管理其他 Workflow 本身。每日 token 消耗审计（Auditor）、自动化优化建议生成（Optimizer）、Workflow 健康监控、Agent 性能分析。Auditor 审计其他 Workflow 的资源消耗，Optimizer 根据审计报告生成优化建议——而 Auditor 和 Optimizer 自身的消耗同样出现在审计日报中，形成了一个自治的监控闭环。

综上，GitHub 这个分层体系的价值不只在于每个 Workflow 各自解决的具体问题，更在于它作为一个整体呈现出的递归结构：底层 Workflow 解决仓库维护的具体问题，上层 Workflow 管理底层 Workflow 的效率和健康，元层 Workflow 监控整个体系的资源消耗。这是一个用 Agent 管理 Agent 的系统工程实践，而非简单地把 LLM 接入 CI 流水线。

这么多工作流，结合大量代码的这个事实。 可想 Token 的消耗是巨大，下面我们看看怎么优化 Token 的使用效率。

优化如何使用Token

✅  自动化本身是一种开销

120 个 Workflow 以 GitHub Actions 形式自动调度和触发，意味着它们 7×24 小时地消耗着 LLM 推理资源。这笔开销并不容易纳入观察，因为它不像人力成本有工资单，不像服务器成本有账单明细，它散布在数百次自动触发的 API 调用中，很容易被忽视。

还有更棘手的是可观测性问题。GitHub 同时使用多个 Agent 框架（Copilot CLI、Claude CLI、Codex CLI 等），每个框架的日志格式和输出粒度不同，有些框架甚至不完整记录 token 消耗数据。在能优化之前，你首先得知道钱花在了哪里，为了获取这个数据，也需要投入工程资源。

回到前言中的框架来理解这个问题：每个 Workflow 每次运行都要构建上下文——把任务描述、相关数据、工具定义等拼装成 prompt 发给模型。这个上下文构建过程中，存在大量可以被消除的浪费：重复发送的工具 schema 定义、注册了但从未被调用的工具描述、本可以用确定性命令获取却被当作 LLM 推理步骤处理的数据读取。这些浪费不影响功能，但日积月累，金额可观。 没有measure 就没有优化，所以我们建立一个可观测的系统来清楚的定义问题是重要的。

✅  建立统一的资源可观测系统

GitHub 解决这个问题的第一步，是利用了其安全架构中的一个现有组件。在 GitHub 的 Agent 体系中，所有模型 API 调用都经过一个统一的 API 代理，这个代理最初的设计目的是安全性的：防止 Agent 直接接触认证凭据和 API 密钥。但它恰好处于一个非常有利的观测位置：所有进出的流量都经过这一个点。

在这个代理层加入 token 计量逻辑后，每个 Workflow 运行结束时都会输出一份标准化的使用报告（token-usage.jsonl），包含每次 API 调用的输入 token、输出 token、缓存命中 token、模型标识和时间戳。这一步本身不优化任何东西，但它解决了最关键的前提问题：让浪费可测量。

这种做法有一个值得注意的工程智慧：不是新建一个监控系统，而是复用已有的安全基础设施。API 代理本来就要处理所有请求，在上面加一层计量的边际成本远低于从零搭建。对于任何规模化使用 Agent 的团队，这个思路都是可借鉴的，找到你的 Agent 系统中已有的"必经之路"，在那里加上数据的采集。

✅  自动化审计

有了数据之后，GitHub 构建了两个相互配合的日常优化 Workflow：

审计 Agent

每日运行，读取近期所有 Workflow 的 token 使用报告，按 Workflow 名称聚合消耗，标记用量出现显著变化的 Workflow，识别异常运行。比如一个通常 4 轮完成的 Workflow 突然跑了 18 轮。审计 Agent 只做诊断，不做修改。

优化 Agent

在审计 Agent 标记了某个 Workflow 后介入。它分析被标记 Workflow 的源码（Markdown 编写的任务描述和工具配置）以及最近的运行日志，然后自动生成一个 GitHub Issue，描述具体的低效之处并提出优化建议。注意它的输出形式是 Issue 而非直接修改。最终决策权仍然在人类手中。

这种"审计-优化"分离的设计是审慎的：审计需要全面性，优化需要精确性，两者对 Agent 的能力要求不同。而把最终执行权留给人类，则避免了自动化优化引入新问题的风险。

✅  优化浪费

基于审计和优化 Agent 的持续运行，最有效的优化集中在三个方面。这三个方向的共通逻辑是：减少 LLM 上下文中不必要的信息，或将不需要推理能力的操作移出 LLM 调用链路。

（1）裁剪未使用的工具定义

在使用 MCP（Model Context Protocol）或类似工具协议的系统中，Agent 需要知道它可以调用哪些工具。这些工具的描述（包括名称、参数 schema、功能说明）会被序列化为 JSON 并附加在每次 API 请求中。由于 LLM API 是无状态的，这份工具清单需要在每一轮对话中重复发送。

Workflow 作者在编写任务时，自然倾向于注册完整的工具集，比如一个 GitHub MCP Server 可能提供 40 个工具，然后让 Agent 自己判断该用哪些。这在功能上没有问题，但在成本上是浪费的：大多数 Workflow 在实际运行中只会稳定地使用其中 2-3 个工具，其余 37 个工具的 schema 定义（每次约 10-15 KB）就变成了纯粹的上下文噪音。

通过交叉比对工具注册清单与实际调用日志，可以精确识别哪些工具从未被使用过，然后将它们从注册列表中移除。这个操作的妙处在于：它不改变 Workflow 的任何行为，Agent 从来就没用过那些工具，但每次调用节省数千 token。 在高频运行的 Workflow 上，累积节省非常可观。

（2）将确定性操作移出 LLM 推理循环

这是更深层、也更具普遍意义的一类优化。

当 Agent 需要获取数据时，比如读取一个 PR 的 diff、列出变更的文件清单，如果这些操作是通过 MCP 工具调用完成的，那么每次获取都是一个完整的 LLM 推理步骤：Agent 需要决定调用哪个工具，构造调用参数，发送请求，接收结果，再基于结果继续推理。这意味着一次简单的数据读取消耗的 token 远不止数据本身的大小，还包括工具选择的推理开销、JSON schema 的序列化开销、以及这次往返在多轮对话历史中的累积开销。

但获取 PR diff 这件事本身是完全确定性的，给定一个 PR 编号，diff 的内容是固定的，不需要任何"推理"就能拿到。用一条 gh pr diff 123 命令，几毫秒就能返回结果，零 token 消耗。

GitHub 的做法是在两个层面推进这种替换：

• 预获取模式：在 Workflow 启动 Agent 之前，在 setup 步骤中用命令行工具预先获取必要数据（PR diff、变更文件列表、issue 内容等），写入工作目录的文件中。Agent 启动后直接读取本地文件，完全绕过了工具调用链路。

• 运行时替换模式：对于 Agent 需要在运行过程中动态决定获取哪些数据的场景，通过透明的 HTTP 代理层让 Agent 可以直接执行命令行工具，拿到结构化数据后继续推理。

两种方式的本质是同一个原则：任何输入和输出都是确定的操作，不应该消耗 LLM 推理 token。 或者用更直白的话说：不调用LLM，就是最节约，最便宜的。

这个原则的适用范围远不限于 GitHub 的场景。在任何 Agent 系统中，架构设计者都应该持续追问一个问题：当前上下文中的哪些信息，是可以用确定性手段获取并直接注入的，而非让模型"思考着"去获取？每找到一个这样的点，就消除了一轮不必要的推理开销。

（3）建立标准化的效率度量

优化的前提是可衡量。但在多模型、多框架的环境中，"token 消耗"本身不是一个公平的比较基准，同样的 10 万 token，在不同模型上的成本差异可能达到 20 倍。从 Sonnet 切换到 Haiku 后，原始 token 数不变，但实际成本可能降低了 4 倍；如果只看 token 数，这个优化就完全看不到。GitHub 为此设计了一个归一化的效率指标：

Effective Tokens（ET）

ET = m × (1.0 × I + 0.1 × C + 4.0 × O)

其中 m 是模型成本系数（根据不同模型的单价设定，如 Haiku=0.25, Sonnet=1.0, Opus=5.0），I 是新处理的输入 token，C 是缓存命中的 token（权重仅 0.1，因为缓存服务的边际成本远低于全新输入的推理成本），O 是输出 token（权重 4.0，因为生成 token 在所有 LLM 计费中都是最昂贵的部分）。

这个指标的价值在于：它让跨模型、跨框架的效率比较成为可能，也让"切换到更便宜的模型"这类优化的效果能够被量化地体现出来。对于需要管理多种 LLM 资源的团队，建立一个类似的归一化指标是成本治理的基础设施之一。

✅  实际效果与仍然困难的地方

通过上述优化，GitHub 在其高频 Workflow 上取得了显著的成本降低。以 issue 自动分诊为例（平均每天运行近 7 次，峰值超过 15 次），单次运行的 ET 降低了约 62%，在观测期内累积节省了约 780 万 ET。安全审查、冒烟测试等 Workflow 的 ET 降幅也在 40%-60% 之间。考虑到这些 Workflow 是每日高频运行的，单次的成本节省乘以调用次数，复利效应显著。

但即便有了审计与优化的自动化闭环，三个根本性挑战依然没有被解决：

第一，缺少结果质量的衡量。 

当前的可观测性集中在过程指标上，如 token 数、交互轮次、工具调用完成率，但没有结果指标，固无法判断优化后 Workflow 的输出质量是否下降。一个更轻量的模型跑了更少的轮次，指标上看是"优化"，但可能产出了更差的结果。

第二，工作负载变化的干扰。

同一个 Workflow 每次运行处理的任务量差异巨大。一个 5 行 bugfix PR 和一个 200 行重构 PR 消耗的 token 量可能相差 10 倍。这意味着 token 消耗的波动很难被准确归因为"效率变化"还是"工作量变化"。GitHub 自己也遇到了这个问题：某个 Workflow 在优化后 ET 反而增加了 5%，但进一步分析发现，观测期内大型 PR 的占比从 39% 上升到了 65%。优化实际上生效了，但效果被更重的工作负载掩盖了。

第三，配置错误的破坏力被低估。

GitHub 分享了一个极端案例：某个代码质量检查 Workflow 一度是整个项目中 ET 消耗最高的。原因是一行配置错误：沙箱的安全策略只允许相对路径的文件访问，但 Workflow 把测试文件复制到了 /tmp/ 目录下。Agent 每次尝试编译都被安全策略拦截，无法使用编译器，于是陷入了 64 轮的无效重试循环。试图通过手动阅读源代码来"模拟"编译器本应告诉它的信息。修复这一行配置后，循环消失，token 消耗回归正常。这个案例说明：在 Agent 系统中，一个微小的环境配置错误可能导致数量级的资源浪费，且很难从外部特征上被区分出来。它看起来就像"这个任务比较复杂，Agent 需要更多轮次"。

经验总结

把前面三个层次的讨论串联起来，呈现出一条清晰的因果链：

Agent 快速生成大量代码

引入技术债务、代码冗余、安全风险

构建自动化 Workflow 系统性管理风险

大量 Workflow 消耗可观的 LLM 推理资源

元层 Agent（审计 + 优化）治理 Workflow 成本

元层 Agent 自身的消耗也需要被纳入监控

从这条递归的因果链条中，可以提炼出几个对所有使用代码 Agent 的团队都有参考价值的原则：

原则一：区分需要推理的操作和不需要推理的操作。

在整个 Agent 系统中，回报最高的优化往往不是"让模型推理得更好"，而是"减少不必要的推理"。获取一个 PR 的 diff 内容是确定性操作，列出变更文件是确定性操作，读取一个配置文件是确定性操作。这些都不需要 LLM 的参与。好的 Agent harness 应当在架构层面清晰地区分：哪些步骤需要 LLM 的判断能力，哪些步骤只需要确定性执行后将结果注入上下文。 每一个被错误归类的操作，都是不必要的 token 支出和可以避免的幻觉风险。

原则二：工具注册应当按需精简，定期审计。

在工具调用协议（无论是 MCP、Function Calling 还是其他形式）下，注册的工具越多，每次请求携带的 schema 开销越大。而实践表明，大多数 Agent 任务只会稳定使用少数几个工具。应当将工具注册视为一种需要定期审计的资源配置：通过比对注册清单与实际调用日志，移除从未使用或极少使用的工具。这不仅节省 token，还能减少 Agent 在工具选择上的决策空间，降低选错工具的概率。

原则三：可观测性和度量是一切优化的前提。

在没有资源消耗数据之前，所有关于"哪里浪费了"的讨论都是猜测。对于任何规模化使用 Agent 的团队，第一步永远是：建立统一的资源使用日志，让消耗可度量。 理想的做法是在 Agent 系统的"必经之路"上。比如 API 代理层、网关层，加装计量逻辑，而非要求每个 Agent 框架各自实现日志输出。统一入口意味着统一口径，这对跨框架的比较和归因至关重要。

原则四：用 Agent 审查 Agent 是可行的，但需要控制边界。

GitHub 的审计-优化闭环证明了"用 Agent 管理 Agent"不只是概念上的优雅，工程也上可行。设计这种闭环时需要注意两个边界：审计和修改应当分离。审计 Agent 只产出诊断报告，不直接修改任何东西，避免自动化审计引入新问题；最终执行权应当保留给人类。优化建议以 Issue 或 PR 的形式提交，由人来决定是否采纳。这种设计在效率和安全之间取得了平衡。

原则五：追求收敛，而非追求速度。

回到前言中的核心观点：当需求描述不完整、隐含约束不在上下文中时，Agent 生成的代码可以很快，但不一定解决真正的问题。真正重要的不是一次生成的速度，而是整个系统能多高效地收敛到正确结果。通过代码审查发现质量问题，通过自动化 Workflow 减少已知风险，通过 token 审计控制成本，通过人类判断弥补上下文缺失。每一层保障都在缩小模型输出与目标解法之间的距离。速度是手段，收敛才是目的。

结语

Agent 代码时代已经是当下的现实。GitHub 平台上每五次代码审查中就有一次涉及 Agent，120 多个自动化 Workflow 在后台持续运转，元层 Agent 每天审计着其他 Agent 的资源消耗。

但穿透这些工程实践的表面，底层逻辑可以总结为：语言模型仍然是一个无记忆的条件续写器，它的全部能力取决于你送进去的上下文。Agent 的价值不在于它能生成多少行代码，而在于整个系统，从上下文的组织到工具的调用，从质量的验证到成本的控制，能多高效地将模型的概率输出转化为可靠的工程结果。

最便宜的 LLM 调用，是不调用。最有价值的代码审查，不是逐行读 diff，而是带着只有你才拥有的上下文做出只有人类才能做的判断。

Agent 时代不属于生成最多 token 的人，而属于最善于组织上下文、最善于划定推理与确定性操作的边界、最善于将模型能力转化为可靠结果的人。放手让模型做它擅长的事： 总结、续写、抽取等，确定行的事交给代码，人类则不断提升自己的判断力， 把有限瓦数的大脑的注意力带宽放到那些真正重要的事情上。

参考资料：

2026-05-07 《Agent pull requests are everywhere. Here's how to review them》https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/

2026-05-07 《Improving token efficiency in GitHub Agentic Workflows》https://github.blog/ai-and-ml/github-copilot/improving-token-efficiency-in-github-agentic-workflows/

2026-05-07 《Grewal et al., More Code, Less Reuse: Investigating Code Quality and Reviewer Sentiment towards AI-generated Pull Requests, MSR'26》https://arxiv.org/abs/2601.21276

2026-01-29 《More Code, Less Reuse: Investigating Code Quality and Reviewer Sentiment towards AI-generated Pull Requests》https://arxiv.org/abs/2601.21276