1. 66.4% 这个数字到底在说什么先把结论摆在前面66.4% 不是某个模型的智商分数也不是AGI 达成度它来自 Terminal-Bench 这类终端任务基准上的通过率。Terminal-Bench 的设计思路很直接——给一个真实的命令行环境让 Agent 在有限步数内完成一个可验证的目标比如修复构建脚本、定位日志里的异常、按规范生成一批文件、跑通一条数据处理链路。评分方式是任务级的通过/失败最后算总通过率。66.4% 意味着大约三分之二的任务被完整解决剩下三分之一要么超步数、要么改错文件、要么在验证环节翻车。这个数字之所以被反复讨论是因为它踩在了一个心理阈值上。低于 50% 时大家默认这玩意儿还得人盯着超过 60% 之后很多人开始重新评估我到底还需不需要自己敲这些命令。但这里有个容易被忽略的细节基准任务的分布是人为挑选的偏向可自动验证、边界清晰、单文件或小范围改动的场景。真实工作里大量的时间花在需求澄清、跨模块影响评估、和同事对齐接口这些无法被基准覆盖的环节上。所以 66.4% 更像是一把尺子量出来的一个切面而不是一张全景图。我在实际使用 Coding Agent 的过程中有一个很深的体会它在目标明确、反馈即时的任务上表现远超预期但在目标模糊、需要反复确认的任务上会迅速退化。这不是模型能力的问题而是任务结构的问题。终端任务恰好是前者——命令跑完有明确的退出码和输出对错一目了然。理解了这一点你就能判断哪些活可以放心交出去哪些活必须自己扛。2. Terminal-Bench 的任务结构决定了分数上限2.1 任务是怎么被构造出来的Terminal-Bench 的题目通常包含三部分一个初始环境可能是一个有 bug 的仓库、一份不完整的配置、一堆待处理的文件、一段自然语言描述的目标、以及一个隐藏的验证脚本。Agent 拿到前两部分通过执行命令来探索环境、修改文件、运行测试最后验证脚本判断是否达标。这个结构决定了它天然偏向可脚本化验证的任务。我拆过几道典型题目发现它们有几个共同特征目标状态可以被一条命令检验比如pytest全绿、某个文件存在且内容匹配正则、初始环境是自包含的不依赖外部网络和私有服务、任务描述里隐含了足够的线索不需要额外追问。这三点凑齐任务才可复现、可评分。反过来说任何不满足这三点的真实工作都不在这个基准的覆盖范围内。2.2 为什么 66.4% 不等于能替代三分之二的工作这里要区分两个概念任务通过率和工时替代率。一个任务通过不代表它省下了人类完成该任务的全部时间。Agent 在探索阶段可能跑了大量无效命令在失败重试上消耗了很多步数最后虽然通过了但总耗时未必比人短。更关键的是通过率是按任务数算的而真实工作里任务的价值分布极不均匀——一个关键模块的重构可能顶得上一百个琐碎的小修小补。我自己的经验是把 Agent 用在高频、低风险、验证成本低的任务上收益最明显。比如批量重命名、按模板生成配置文件、跑一遍 lint 并修复明显问题、把一段日志里的错误模式提取出来。这些任务单个人做也就几分钟但一天累积下来很可观而且失败了立刻能发现。反过来涉及数据库迁移、权限变更、生产配置修改的任务即使 Agent 声称通过率很高我也不会让它直接执行。2.3 基准分数和真实体感之间的落差来源落差主要来自三个地方。第一是环境差异基准环境干净、依赖固定真实环境里可能有历史遗留的脏数据、版本冲突、权限问题。第二是反馈延迟基准里跑个测试几秒钟出结果真实项目里一次完整构建可能十几分钟Agent 的试错成本被放大。第三是隐性约束基准任务不会告诉你这个函数被三个下游服务依赖改签名要同步更新但真实工作里这种约束无处不在。提示看到任何基准分数先问三个问题——任务怎么选的、验证怎么做的、失败怎么算的。这三个问题的答案决定了这个分数能外推到多远。3. Coding Agent 在终端里的真实工作链路3.1 从自然语言到命令序列的翻译过程一个 Coding Agent 处理终端任务时内部大致走这么几步解析任务描述提取关键目标和约束扫描当前目录结构建立环境认知规划一个初步的命令序列执行第一条命令读取输出根据输出调整下一步循环直到达成目标或耗尽预算。这个循环里最关键的是根据输出调整这一步它决定了 Agent 是在盲目试错还是在有方向地收敛。我观察过不少 Agent 的执行轨迹发现表现好的那些有一个共同点它们会先做低成本的信息收集ls、cat、git status、grep再动手改东西。表现差的则倾向于直接猜一个命令然后跑错了再猜。这个差异在简单任务上不明显但在复杂任务上会迅速拉开差距。所以如果你在配置 Agent 的工作流不妨在系统提示里明确要求它先侦察、后行动。3.2 工具调用中的步数预算与收敛策略步数预算是 Agent 的一个硬约束。给太少它还没摸清环境就被迫交卷给太多它可能在错误方向上反复折腾。我的经验是对于定位并修复一个已知类型的 bug这类任务20 到 40 步通常够用对于从零搭建一个可运行的小项目可能需要 60 步以上。关键是设置一个合理的提前终止条件——比如连续几步没有任何文件变更或者验证命令连续失败且错误信息没有变化就应该停下来重新规划而不是继续硬试。这里有个反直觉的点有时候给 Agent 更多步数反而降低成功率。因为它会在一个错误假设上越陷越深每多跑一步就多一层沉没成本越不愿意推翻重来。所以我在自己的流程里会加一个重启阈值——如果同一个错误出现三次就强制清空上下文重新开始而不是让它继续在旧轨迹上修补。3.3 验证环节为什么是成败分水岭验证环节是很多 Agent 翻车的地方。它们可能改对了文件但没跑验证命令或者跑了验证命令但没正确解读输出又或者验证通过了但改动了不该改的东西。我见过最典型的失败模式是局部正确、全局破坏——Agent 为了让某个测试通过把另一个测试搞挂了而它只盯着眼前那个测试。所以一个可靠的 Coding Agent 工作流必须包含回归检查这一步。具体做法是在修改前后各跑一次完整的测试套件或者至少是受影响的模块对比结果。如果修改前就有失败的测试要记录下来作为基线避免把历史问题算到 Agent 头上。这个习惯看起来笨但能挡掉大量看起来通过了其实埋了雷的情况。4. 把 Agent 用出价值的三类场景4.1 场景一环境侦察与信息聚合这是我认为最被低估的用法。让 Agent 去回答这个仓库的构建流程是什么哪些文件引用了这个即将废弃的接口最近的提交里有没有引入新的依赖这类问题它做得又快又全。人类做这些事要来回切窗口、翻文档、记笔记Agent 可以一次性把相关文件、命令输出、依赖关系整理成一份结构化报告。我常用的一个模式是给它一个模糊的问题要求它输出结论 证据 不确定的地方。比如问这个项目的测试覆盖率大概什么水平它会去跑覆盖率工具、读配置、统计结果最后告诉你数字和统计口径。这种任务风险极低因为不改任何东西纯读操作即使它理解偏了你一眼就能看出来。4.2 场景二重复性代码与配置的批量生成第二类高价值场景是批量操作。比如给一批结构相似的模块补上统一的日志埋点、把散落在各处的硬编码配置抽到统一文件、按新规范重命名一批函数。这类任务的特点是模式固定、单次改动小、但数量多人工做既枯燥又容易漏。Agent 的优势在于它不会因为重复而走神只要模式描述清楚它能一致地执行到底。但这里有个前提模式必须能被明确表达。如果你说把代码改得优雅一点它会给你一堆主观判断如果你说把所有console.log替换成统一的 logger 调用logger 从/utils/logger导入它就能准确执行。所以用 Agent 做批量任务功夫花在把规则写清楚上而不是花在盯着它改上。4.3 场景三失败日志的定位与初步修复第三类是排错。给 Agent 一段报错日志和一个可复现的命令让它定位根因并给出修复方案。它在从错误信息反查代码位置这件事上效率很高尤其是当错误信息里包含文件路径和行号时。我经常用它来快速判断这个报错是环境问题还是代码问题因为它会去检查依赖版本、环境变量、文件权限这些容易被忽略的地方。不过要注意Agent 给出的修复方案需要你复核。它可能治标不治本比如把报错的那行注释掉让程序跑起来而不是解决根本原因。我的做法是让它同时给出临时绕过方案和根本修复方案然后我自己判断该用哪个。这个习惯能避免很多跑是跑起来了但埋了更大的雷的情况。5. 那些基准分数不会告诉你的坑5.1 上下文污染导致的连锁错误Agent 在一个会话里待久了前面犯的错会污染后面的判断。比如它一开始误以为某个配置文件在 A 目录后面所有操作都基于这个错误假设即使中途有证据表明文件其实在 B 目录它也可能因为已经做了这么多步而继续错下去。这个现象在长任务里特别明显。我的应对办法是分段执行。把一个长任务拆成几个独立的子任务每个子任务开一个新的会话只带上必要的上下文。这样虽然损失了一些连续性但避免了错误累积。另一个办法是在提示里明确要求它每完成一个阶段就重新确认当前状态强制它定期回到事实层面。5.2 权限边界与破坏性操作的拦截Agent 默认不会区分读操作和写操作的风险等级。它可能为了排查问题而执行rm、git reset --hard、修改系统配置这类破坏性命令。基准环境里这些操作无所谓因为环境是一次性的真实环境里可能就是灾难。所以我在任何真实项目里用 Agent第一件事是设置权限边界只读操作放开写操作限制在特定目录破坏性命令一律需要人工确认。具体实现方式取决于你用的工具但原则是一样的——把能做什么和允许做什么分开。这个设置花不了几分钟但能挡掉绝大多数手滑级别的损失。5.3 过度自信的输出与人工复核点Agent 在报告结果时往往语气笃定即使它其实不确定。它会说已修复而不是我改了 X你验证一下。这种表达方式容易让人放松警惕。我的习惯是不管它说得多肯定关键改动都要自己跑一遍验证。尤其是涉及数据、金额、对外接口的改动复核这一步不能省。复核也有技巧。不要只看它改了什么还要看它没改什么。比如它说修复了登录逻辑你要确认它没有顺手改动权限校验。一个实用的方法是让它输出改动清单逐条对照你的预期多出来的改动要么有合理解释要么回滚。6. 人类程序员的坐标系该怎么重新校准6.1 哪些能力在贬值哪些在升值贬值的是记忆型和检索型能力——记住某个 API 的签名、知道某个报错对应哪个 Stack Overflow 答案、熟练敲出一段样板代码。这些 Agent 做得又快又准而且不会忘。升值的是判断型和定义型能力——判断一个方案在长期是否可维护、定义清楚一个问题到底要解决什么、在多个可行方案之间做取舍。这个转变对程序员来说其实是好事。以前大量时间花在把想法翻译成代码上现在这部分被压缩了更多时间可以花在想清楚要做什么上。但前提是你得主动往这个方向走而不是停留在和 Agent 比谁敲代码快的层面——那个比较没有意义你赢不了也不该赢。6.2 从写代码的人到定义问题的人我自己的转变过程是这样的以前拿到需求直接想这个功能怎么写现在先想这个需求背后的真实目标是什么、有没有更简单的实现方式、验收标准是什么。把这些问题想清楚之后再决定哪些部分交给 Agent、哪些部分自己写。这个顺序的调整让我的产出质量明显提升因为很多需求在想清楚阶段就被简化甚至否决了。定义问题的能力还包括把模糊需求拆成可验证的子任务。Agent 擅长执行明确的任务不擅长处理模糊的目标。所以你的价值很大程度上体现在把模糊变明确这一步。这一步做得好Agent 的产出就稳定做得差Agent 就会给你一堆看起来对但用不上的东西。6.3 协作模式把 Agent 当同事而不是工具最后一个校准点是心态。把 Agent 当更快的自动补全用你只能拿到边际收益把它当一个需要清晰指令、会犯错、需要复核的同事用你才能拿到结构性收益。这意味着你要给它足够的上下文、明确的验收标准、以及犯错后的反馈。就像带新人一样指令越清晰产出越可靠。我现在的工作流里Agent 承担了大概三成到四成的执行工作主要集中在信息收集、批量修改、初步排错上。剩下的六到七成还是自己做包括架构决策、关键逻辑、以及所有需要对外负责的部分。这个比例不是固定的会随着任务类型浮动但核心原则不变Agent 负责做我负责判断做什么和判断做得对不对。7. 一套可复用的 Agent 协作流程7.1 任务分级什么交给它什么自己扛我按风险 × 可验证性两个维度给任务分级。低风险高可验证的直接交给 Agent比如生成测试数据、格式化代码、提取日志信息。低风险低可验证的让 Agent 做初稿自己复核比如写文档、整理会议纪要。高风险高可验证的让 Agent 做但必须跑完整验证比如修改有测试覆盖的业务逻辑。高风险低可验证的自己做Agent 只做辅助侦察比如改数据库 schema、调整权限配置。这个分级不是绝对的但能帮你在想偷懒和怕出事之间找到一个理性的平衡点。关键是每次交出去之前先问自己如果它做错了我多久能发现发现成本越高越应该自己做或者加更多验证。7.2 提示词里的四个必备要素我给 Agent 写任务描述时尽量包含四样东西目标要达成什么、约束不能碰什么、验收标准怎么算成功、输出格式结果怎么给我。这四样写清楚成功率会明显提升。举个例子与其说优化一下这个脚本不如说把这个脚本的执行时间降到 10 秒以内不能改变它的输出格式改完后跑./run.sh --test验证把改动点和耗时对比告诉我。约束这一项特别容易被忽略但它往往是防止 Agent 闯祸的关键。明确告诉它不要修改 X 目录不要升级依赖版本不要动数据库能挡掉很多意外。我甚至会在提示里写如果不确定某个操作是否安全先问我虽然它不一定每次都问但至少给了它一个停下来的理由。7.3 结果验收三个必须检查的点Agent 交付结果后我固定检查三件事。第一改动范围是否符合预期——有没有多改、少改、改错地方。第二验证是否真的通过——它说通过了我要自己跑一遍或者至少看它跑的输出。第三有没有引入新的问题——跑一遍回归测试对比修改前后的结果。这三步看起来繁琐但熟练之后也就几分钟的事。而且它能帮你建立对 Agent 的信任校准——你会逐渐知道它在哪类任务上可靠、哪类任务上容易出问题从而更精准地分配工作。这个校准过程本身就是一种能力积累比单纯记住某个模型的分数有用得多。8. 关于 AGI 讨论的一点个人看法66.4% 这个数字被拿来讨论 AGI我觉得更多是话题性的而不是技术性的。AGI 的定义本身就没有共识有人按能否完成任意人类任务算有人按能否自主设定目标算有人按能否持续学习算。Terminal-Bench 测的是在特定类型的终端任务上能否达成目标这个能力和 AGI 之间的距离取决于你用哪个定义。我自己的判断标准比较朴素看它能不能在我没把问题说清楚的时候通过提问把问题变清楚。目前我试过的 Agent 里能做到这一点的还很少。它们更擅长执行明确指令不擅长在模糊中主动澄清。这个能力一旦突破讨论 AGI 才有实质意义在那之前66.4% 就是一个有用的工程指标告诉我们这类任务可以放心交出去了仅此而已。把注意力放在怎么用好它上比争论它是不是 AGI更有产出。我见过太多人花时间讨论模型的上限却很少花时间研究怎么把它的下限用稳。而实际工作中决定成败的往往是下限——它会不会在关键时刻掉链子、会不会在你没注意的时候改错东西、会不会给你一个看起来对但经不起推敲的答案。把这些下限问题解决好66.4% 也好80% 也好都能变成实实在在的产出。