上一篇的 Claude Code，住在你的终端里，用一个循环招呼你全部的工具。另一条路线把方向反过来：你不用守着它，把任务交出去——排队、执行、交卷，回来的时候，代码已经改好了。
Codex 类的编码 Agent 把这件事做成了产品：云端一支、本地一支。拆开看，两半各有一套工程思路；合起来看，它们刚好回答了一个问题——为什么“编码”会成为 Agent 的第一个战场。
一个任务，两个跑法
先把分工分清。
云端的一支，像一间可以随时托管的任务车间：你把要办的事写清楚递进去，它自己进一个隔离环境，从零开始干活，干完把成果——比如一份改好的代码、一个等待审核的合并请求——交回你手上。全程不需要你盯着。
本地的一支，像一个坐到你身边的同事：在你的机器上、你的仓库里动手，边做边把过程摊给你看，遇到拿不准的先问一句。环境、速度、隐私，全都不用搬家。
两种跑法不是竞品，而是同一支队伍的两个工位：能远程办的事扔到云端，需要沉浸和频繁沟通的留在本地。真正的问题是：这两半，各自是怎么被做扎实的。
沙箱：先关进圈里，再谈自由
让 Agent 跑命令，最让人手心出汗的是这一点：它拿的是你的权限。一条命令敲错，删掉的可能是一个分支，碰坏的可能是系统配置。
所以这类产品的第一课不是“让 Agent 更聪明”，而是“让错误有边界”。常见的做法，是把执行关进一个圈里：
- 文件边界：圈里能看、能改的，只有指定的一小块——通常就是任务所在的工作目录
- 网络边界：默认收紧，需要联网的动作单独走一道批准
- 权限边界：圈内放手让它折腾，一旦要碰圈外的资源，必须升级、必须问人
沙箱的哲学值得多念一遍：它不假设 Agent 不会犯错，它假设 Agent 一定会犯错，然后让错误的代价小到可以承受。圈内随便试错，圈外一步不许。安全不是靠祈祷模型不出错，而是靠设计让出错也翻不了车。
这里有一个所有 Agent 产品都绕不开的取舍：放得越开，越能干，风险越大；关得越紧，越安全，也越憋屈。好的答案通常是“默认收着、按需放开”——开不开那把锁，交给离场景最近的人，也就是你。
云端那半：交给队列，自己去忙
云端跑法的本质，是把“对话”换成“任务”。
对话模式里，你和它同台演出，它一句你一句，你不在，戏就停了。任务模式里，你只是编剧：把需求写清楚、提交，然后可以转身离开。它自己拆步骤、自己动手、自己跑测试验证，没人看着也照演不误。
这套模式带来两个变化。
一是并行。任务互不干扰，就能同时挂出去好几件——你在开会，它在改接口；你在吃饭，它在补测试。你等待一件事的时间，变成了同时推进好几件事。
二是可回传。干完的成果以标准格式交回来：改了哪些文件、为什么改、怎么验证的，一目了然。审查成本被压得很低，你需要做的只剩“要不要”这个判断。
它适合独立、可验证、中途不需要拍板的任务——修一个明确的缺陷、按约定做一次重构、补一片测试。需要频繁讨论、方向随时在变的任务，硬塞给它只会来回打转。
本地那半：环境、钥匙和隐私都留在原处
云端有一个绕不过去的成本：它得先重建一个世界才能开工。你的构建工具链、私有依赖、内网服务、各种密钥——要么复制过去，复杂而且危险；要么它根本跑不起来。
本地跑法把这些麻烦原地消化：环境是现成的，钥匙不用搬家，代码不出你的机器。一个配好本地环境的 Agent，立刻就能干那些需要真实世界的活——启动服务、连着数据库跑测试、复现一个只有内网才能复现的问题。
它的短板同样实在：吃你的机器资源，也吃你的注意力。而且本地不等于随便——圈还是要有，只是圈画在你自己的地盘上。
任务式循环的工程化
前面拆过 Agent 的基本循环：想一步、做一步、看结果、再想。云端产品把这个循环从“一次对话里的插曲”，升级成“可以无人值守跑上几十分钟的正式流程”。变化藏在几个工程细节里：
- 状态可见：任务进行到哪一步、正在动哪个文件，随时可查
- 可中断、可接管：你能看进度、能喊停、能接手调整方向
- 自验证闭环：做完不算完，跑一遍测试、核一遍结果，才叫完成
- 失败可诊断：卡住了，要把“卡在哪、试过什么”整理成人能看懂的东西，而不是无声无息地死掉
把循环工程化，意味着每一步都变成可观测、可干预的正式环节，而不是一口气冲到底的黑盒。这也是“玩具”与“能托管任务”之间的真实差距——模型没换，是流程被做扎实了。
为什么编码是 Agent 的试炼场
这一整个系列都在讲 Agent，但真实世界的 Agent 竞争，几乎都从编码场景开打。不是偶然——编码刚好把 Agent 最需要的东西凑齐了：
- 全程纯文本：读进去的是代码，写出来的也是代码，中间不需要任何专用接口
- 自带评分器：测试、编译、类型检查——对错不由人的嘴说了算，跑一遍就有客观答案
- 试错可回滚：版本控制兜底，改坏了退回去就是，试错成本被压到极小
- 素材取之不尽：真实仓库、真实问题、真实讨论，任务不用编，现成的就有几十万个
四条里最关键的是第二条。别的领域里，“做完了吗、做对了吗”时常要靠人判断；编码场景里，机器自己就能给出答案。一个能自证的场景，才撑得起无人值守的循环。
评测：拿真实仓库当考场
一门技术想跑得快，得先有尺子。Agent 的尺子，这几年换过一次刻度。
早期评测爱出玩具题：给一个假想场景，看它答得像不像。题是编的，标准也是编的，量出来的东西离真实工作很远。
后来风向变了：直接拿开源仓库里的真实问题当考卷——给你真实项目、真实待修的缺陷，看你能不能改到测试全绿。这条路里最有名的名字叫 SWE-bench。分数这里不写：那是变化最快的数字。
这套“真实任务考、客观测试判”的风气，反过来推着产品往前走：敢接受同一把尺子量，就得把可复现、可对比、不挑题这些功夫做实。一个领域开始认真比分数的那天，往往就是它开始长本事的起点。
下一站：开源的那半边
这两篇拆的，都是成品：能用、能配、能观察，但看不到每个选择背后的全部理由。它们的“为什么这样做”，很多时候只能靠推测。
下一站换个方向，去看另一半岛屿——开源 Agent。代码摊在桌上，内核、工具、权限、循环全都翻得到，翻完不满意还能自己改。从 Pi 到 DeepSeek Harness，两条路线不同的代表，正好当标本。