第五章学习笔记：代码是 Agent 的元能力，但可靠性来自验证
本文是对第五章《Coding Agent 与通用 Agent》的学习整理。
一份季度报告，为什么会变成编程任务？
设想我对 Agent 说：“把上季度销售数据整理成一份能给团队看的报告，标出异常波动。”它得找到数据，弄清字段含义，处理缺失值，计算同比和环比，画图，生成文档，最后检查数字、图表和正文是否一致。
如果把每一步都预先做成专用按钮，系统迟早会遇到没覆盖的新格式、新指标或新产物。第五章给出的另一条路是：让 Agent 能写、能运行、能修改代码，把未知任务拆成可执行的小程序。 文件系统则承载脚本、数据、图表、报告和中间状态。代码因此不只用于开发软件，也成了连接已有工具、创建新工具的“元能力”。
但这里有一个容易跳过的条件：生成的程序可以运行，不代表需求理解正确；测试通过，也不代表报告值得信任。读完本章，我记住的主线是：
代码扩大 Agent 的行动范围；Harness 决定这些行动能否被约束、观察、纠错和验收。
从“会写代码”到“能交付”：中间隔着一个闭环
一个最小的 Coding Agent，需要能找文件、读文件、搜索内容、写入或局部编辑文件，以及执行命令或沙盒代码。书中把这些能力展开为 Code Interpreter、Bash、Read、Write、Edit、Glob、Grep 七类工具。这是帮助理解能力边界的清单，不是说系统必须暴露七个独立按钮：同样的操作也可以通过受控的 shell 完成。
真正拉开差距的不是工具数量，而是工作循环。拿“修复一处订单计算错误”来说，我会期待 Agent 留下这样一条可以追溯的路径：
定位报错与相关代码 → 读懂需求和项目约定 → 修改最小必要范围
→ 运行相关测试与静态检查 → 根据失败结果修复 → 核对差异并交付复杂任务在动手前还需要澄清目标、比较方案；架构变化则要同步文档。简单问题可以缩短流程，但不能把“文件写完了”当作“问题解决了”。在我看来，完成标准应写成环境中可检查的结果：测试是否覆盖真实故障、输出是否满足用户要求、有没有引入意外改动。
这也解释了为什么仓库里的项目指令文件有用。AGENTS.md、CLAUDE.md 等把构建命令、风格和禁区留在 Agent 能读取的位置；测试、类型检查、CI 则把一部分约定变成机器能执行的约束。文档帮助 Agent 理解规则，执行层负责阻止违规动作，两者职责不同。
Harness 的价值，是给能力装上可见的边界
第五章延续了第一章的 Agent = Model + Harness。放到 Coding Agent 上，我会用四个问题检查 Harness：
| 问题 | 在代码任务中的落点 |
|---|---|
| 什么算完成？ | 需求验收、测试、静态检查、审查标准 |
| 哪些动作可以做？ | 工作区、依赖规则、权限、危险命令限制 |
| 出错后能看到什么？ | 带位置的错误、完整日志入口、工具执行结果 |
| 改坏了怎样恢复？ | Git 差异、快照、沙盒、可回滚的部署 |
这套设计把软件工程长期积累的基础设施变成 Agent 的反馈环境。目标明确且结果可自动检查时，Agent 最容易稳定推进；目标模糊时，再快的测试循环也可能只是让它更高效地做错事。比如“让 UI 更好看”首先缺的是审美标准和目标用户，单靠 lint 无法解决。
我还会多加一个判断：验收不仅检查结果，也检查过程。 删除出错模块后测试通过，或清空数据后数据库恢复可用，都可能拿到漂亮的“成功”信号，却违背任务本意。因此危险动作需要独立的执行限制，不能只依赖最终分数。
可靠的 Agent 不会假装故障不存在
写代码时出错很正常。生产级 Agent 的差异，在于能否把故障分清楚：API 限流、工具参数错误、上下文结构损坏、反复执行同一命令，处理方式显然不该一样。
本章的故障恢复设计给我三个很实用的提醒：
- 先分类再重试。 网络抖动可以退避重试；权限不足、工具不存在或参数非法，原样重试只会浪费时间。
- 观察是否真的有进展。 相同工具和参数反复出现、流式连接长期没有新输出、恢复逻辑自身又触发故障，都需要计数、看门狗和熔断上限。
- 错误要成为可用反馈。 让 Agent 看见“哪个参数不符合约束”“哪一行检查失败”，比只返回“执行失败”更有助于修正。
跨模型接管尤其能说明“状态”不能只存在于某家厂商的消息格式里。工具调用、结果、可读的思考摘要可以存成中立轨迹；厂商专有凭证不能直接搬给另一家。这个设计除了故障切换，也为后续重放、评估和经验提取保留了基础。这里的具体兼容路径取决于目标模型接口，不能从“有轨迹”直接推断“必定能无缝接管”。
为什么代码被称为“元能力”？看它创造了什么
第五章后半部分列出六个应用方向。我更愿意按代码作用于谁来理解它们。
先作用于 Agent 自己：计算、规则和新工具
代码可以把容易算错的问题交给确定性执行器：模型负责理解题意、建立变量和关系，程序负责计算或求解。但“程序算对”只保证它忠实执行了写进去的假设；如果模型把题意形式化错了，答案仍然会错。
业务规则也是如此。以取消机票为例，自然语言规则能帮助 Agent 向用户解释政策；工具参数里的核对项能提示它先查订单；真正决定能否取消的校验，必须在执行工具内部读取数据库里的舱位、保险、航段状态和服务端时间。模型自报的事实可以帮助审计，不能充当最后的真值。 对退款、付款、删除等不可逆动作，这条边界尤其重要。
遇到陌生日志格式或没有现成 SDK 的服务，Agent 还能临时生成解析器、转换脚本或 API 适配器。这种能力减少了对预制工具的依赖，但自动适应并非总是好事：格式变化也可能是上游故障。解析器在热更新前，应先用样本、回归测试和异常阈值区分“预期的新格式”与“值得报警的坏数据”。
更进一步，Agent 可以基于经过验证的实现模板创建新 Agent，或诊断自身运行环境。这是“自举”的方向，但复制模板只降低起步风险；新生成系统的权限、上下文协议和实际行为仍需单独验收。
再作用于交付物：报告、视频、界面
PPT、视频和图表可以用代码精确描述结构与参数。问题在于，代码正确并不等于渲染结果可读。书中使用“提议者—审核者”循环：一个 Agent 生成代码，另一个观察真正渲染出的页面或视频帧，指出具体页码、位置和问题，再让前者修改。审核者接触了提议者原先没有看到的环境结果，这比只让模型自评源代码更有意义。
但代码也不是所有内容的最佳表示。带尺寸公差的零件适合参数化 CAD，因为形状可以用少量尺寸精确表达并验证；绿植或人脸这类高细节、重观感的内容更适合生成模型。选择生成方式，要看产物能否被紧凑描述、是否要求精确和后续可编辑。
生成式 UI 则让 Agent 把一次次追问变成表单，把难读的结果变成交互图表。标准卡片、输入框和表格可由受信任组件目录渲染；若确需生成 HTML 或 JavaScript，则必须按可执行代码对待。自然语言转 SQL 的 Artifact 模式也遵循同一思路：模型生成查询，数据库执行，结果直接进入界面，避免模型搬运大量数据；执行层仍要限制只读权限、查询范围和资源消耗。
最后要问：谁来约束它生成的软件？
动态生成应用有一个更深的风险：如果权限判断也随应用代码一起被改写，Agent 漏掉一项校验就可能跨越数据边界。本章提出把最终裁决放到稳定的数据访问层，由受信任的运行时绑定用户、租户和角色，让生成代码只能以受限身份读写。
这个观点也适用于一般 Coding Agent。它可能读取含提示注入的网页、仓库文件或工具输出，同时拥有私有数据和对外通信能力；持久记忆还可能让一次注入跨会话留存。沙盒、最小文件权限、网络出口控制、资源限额和记忆写入审查，应该作用在模型之外。安全目标不能是期待它每次都“记得小心”，而是让危险动作在执行层受到约束。
实验结果提醒我：不要把架构直觉当成经验事实
正文提出了不少合理的机制，但实验台账里的对照结果并不总支持预期。以下数字是仓库记录的结果，不是我独立复现的结论：
| 对照 | 仓库记录 | 能支持的判断 |
|---|---|---|
| 实验 5-3：30 道 AIME 2024 数学题 | 代码辅助 53.3%，纯思考 36.7%；配对检验 p=0.125 |
这个样本里代码组数值更高，但不足以宣称显著提升 |
| 实验 5-4：84 道 K&K 逻辑题 | 代码辅助 39.3%，纯思考 75.0% | 形式化步骤可能引入新错误，不能默认“加求解器更好” |
| 实验 5-5：60 组配对客服任务 | 代码化规则 91.7%，控制组 95.0%；p=0.6875 |
代码化规则的可靠边界有价值，但本次任务成功率未见提升 |
| 实验 5-6：论文转 20 页 PPT | 双 Agent 与单 Agent 最终均得 95 分；峰值上下文分别为 24,186 与 92,601 token | 分工在这次对照中节省上下文，不能说最终质量更高 |
我从这些反例里得到的不是“代码没用”，而是更具体的判断：工具能否带来收益，取决于模型会不会正确调用、形式化有没有出错、评测看的是成功率还是权限边界，以及任务本身是否适合代码表达。 书中的实验结果也有样本、模型和题集边界；迁移到自己的场景，仍需重新测。
写在最后
第五章让我把“会写代码”拆成了两件事：一件是生成能力，遇到未知格式、任务或产物时能现场造出方法；另一件是工程能力，把生成的方法放进可观察、可验证、可恢复、受权限约束的闭环。
前者解释了 Coding Agent 为什么能成为开放任务型通用 Agent 的核心；后者决定它是否值得被委托真实工作。对流程固定的垂直 Agent，代码可能只是一件工具，未必需要成为架构中枢。但无论哪种 Agent，只要开始让模型生成并执行代码，我都想先问：它依据什么事实写、由谁验证结果、出了错怎样停、越界时由哪一层拦住？
第五章配套实验记录
实验5-1：跨厂商的轨迹接管
Kimi 与 Gemini 双向切换的六个真实 API 单元中，中立格式完成 2/2 个方向，直传与剥离各完成 1/2；所有成功单元均得到正确的 6,944 元预算且没有重复调用。本次未覆盖 Anthropic，不能视为完整三厂商协议通过。