本文是「Agent 开发实践与思考」系列第 11 篇。系列目录：
- 2024
- 2025
- 01-28 长任务不失忆：上下文压缩、交接文档与子任务隔离
- 02-25 MCP 用了三个月：工具标准化之后 Agent 设计变了什么
- 03-25 拆解 Coding Agent：为什么”写代码 + 文件系统”是通用 Agent 的内核
- 05-13 Agent 如何用代码完成推理、校验、适配与展示（本篇）
上一篇拆解 Coding Agent讨论了”写代码 + 文件系统”为何是通用 Agent 的内核，重点仍是程序员使用的工具。这半年做团队基建和 AI 开发助手时，我遇到不少非编程任务也需要模型写代码。代码不一定是最终交付物，也可以承担计算、校验、系统适配和信息展示。下面记录四种用法及其限制。
用代码验证计算
模型处理数值题时会生成文本，不会执行算术。涉及汇率换算和阶梯费率的对账，步骤一多，文本推理中的错误很难被中途发现。我做过一批 30 条多币种结算题的对比：直接要求模型计算时，没有一次全部答对；要求它先写 TypeScript 并执行后，剩下的错误都是取数口径问题，计算本身没有出错。
要求模型写一段 TypeScript 后，部分推理步骤会变成可执行语句，解释器负责计算。在输入和实现正确的前提下，算术错误可以通过执行结果发现。仍可能出错的是业务逻辑，例如汇率日期取错、费率档位理解错误。这些问题可以审查，也可以更换数据重跑。纯文本推理的结论无法执行，只能靠人工检查。
AI 开发助手治理国际化硬编码时也有类似情况。第一步需要统计仓库中货币硬编码、时间格式和文案等问题的数量与占比。最初让 AI 读代码后口头汇总，扫描几百个文件后，两次的统计数字对不上，AI 也无法说明差异来源。后来改为让它写遍历脚本，按模式匹配、分类计数并输出 CSV。统计结果可以复现；对分类有争议时，修改规则后重新执行即可。讨论也从统计是否准确，转为某条规则应归入哪一类。
这个任务没有要交付的软件，但脚本提供了可复现的统计过程。
用代码执行确定性规则
提示词中的规则由模型按上下文理解和执行，代码中的规则可以直接判定。“价格保留两位小数”、“汇率取结算日收盘价”、“未登录用户不能看成本价”这类规则，写在提示词中仍可能被遗漏。将它们实现为校验函数，在违反规则时返回错误，可以把检查交给系统执行。
判断方式是看规则能否写成可判定的断言。能判定的规则适合写入代码。语气是否得体、文案是否通顺、判断是否合理等依赖上下文的内容，仍需要提示词和人工判断。代码负责确定性条件，提示词处理需要解释的部分。
规则进入代码后会有 diff 和测试。业务方修改价格规则时，过去需要改提示词中的一段描述，再凭经验回归；现在可以修改函数和用例，运行后查看影响。代码中的规则仍可能过时或实现错误，因此仍需要测试、评审和变更管理。
团队基建项目中，AI 累计写了约 10 万行代码。我能检查架构分层和验收标准，无法逐行检查实现。因此要求 AI 为每个模块同时交付校验脚本，包括接口签名检查、构建产物检查，以及迁移前后的行为对比。这些脚本为每轮修改提供反馈：如果改动 A 模块破坏了 B 模块，下一轮执行可以发现问题，而不必等到几天后由人发现。这和 TDD 的做法相近，只是驱动者是 Agent。复盘时，我把它列为项目能够完成的两个主要原因之一，另一个是按模块分层提供上下文。
用代码连接缺少接口的系统
MCP 那篇文章讨论过工具生态。现实中，许多内部系统没有 API，也未必有人会为它们开发 MCP server。需要接入这类系统时，Agent 可以先编写适配脚本。
AI 开发助手需要理解 Native 工程。工程使用自定义的组件组织方式，社区工具无法直接解析。AI 编写遍历和解析脚本，提取类、依赖和入口，再根据这些结构化数据生成文档。脚本补上了原系统缺少的解析能力。
另一个例子是旧配置平台。它只有 Web 页面，没有开放接口。业务方需要批量导出几百条配置，评估迁移工作量。手工导出预计需要两天，Agent 编写的脚本通过模拟登录、抓取页面、解析 HTML 后导出 JSON，执行约一小时。脚本在这次迁移评估中提供了批量读取能力。
因此，接入 Agent 时不必预先准备所有工具。只要允许编写和执行代码，就可以按任务补充临时工具。这类脚本通常较粗糙，适合一次性取数、批量迁移评估和临时对账。关键链路上的长期集成仍需要正式接口和维护计划。我现在会先判断需求是否会持续超过三个月：周期短的需求可使用临时适配脚本，周期较长的需求再评估正式建设是否值得。
用代码生成一次性界面
数据汇报中，文本不一定便于比较。Agent 汇总治理进度时，可能输出”共 1283 处，其中货币类 312 处，占比 24.3%“。读者还需要自行比较数字。让 Agent 生成 HTML 页面，用表格和图表展示数据，可以直接在浏览器中查看。
Claude Artifacts 使用的也是代码生成界面的方式。对我而言，HTML 和 JavaScript 是较容易让模型生成和修改的 UI 形式。在一次性页面中，它比直接操作复杂 GUI 编辑器更容易检查和迭代。
基建项目收敛期间，我需要每周向团队同步各业务线的迁移进度。原先是维护表格截图并发到群里。后来让 Agent 读取迁移脚本输出的状态文件，生成静态页面，把进度条、阻塞项和各仓库校验通过率放在同一屏。这个页面没有单独排期，只需一段对话生成。对于内部的一次性看数需求，生成页面的投入通常低于开发长期功能。
这类界面适合一次性、低频和个人使用的需求。多人使用、需要长期维护，或有权限和数据安全要求的界面，仍应按常规方式开发。生成结果可以作为原型。
执行、隔离与版本管理
以上用法都依赖几个前提。
第一，代码能执行不表示结果符合要求。AI 开发助手做 Native 迁移时，曾生成可以编译和运行的代码；与原工程对比后发现，部分功能丢失，另有组件使用了 className 却没有对应的样式定义。一次执行通过，只说明已覆盖的路径没有触发运行时错误，不能证明逻辑满足业务要求。校验脚本需要存在，校验口径也需要由人根据业务要求确定。AI 编写的校验脚本同样可能遗漏问题，不能作为唯一验收依据。
第二，执行环境需要隔离。Agent 编写的代码会读取文件和发送请求；它可能生成危险操作，也可能在解析不可信数据时受到注入影响。我们将脚本统一放到容器中执行，按任务白名单挂载目录，网络出口单独经过代理，数据库只提供只读账号。这些约束由执行环境保证，不依赖模型是否遵守提示词。
第三，反复使用的代码需要进入版本管理。一次性脚本用完后删除没有问题，但适配器和校验脚本如果被持续使用，就应进入仓库并经过 review。我们曾遇到一个 AI 生成的校验脚本被多个任务复用。后来有人让 AI 修改脚本但没有提交记录，校验口径随之变化，一批基于旧口径的结论只能重新处理。脚本也需要版本和变更记录。
结语
我目前的判断是，Agent 的交付物会包含更多代码制品，而不只是文本回答。代码可以接入执行、测试、diff 和回滚等机制，因此更容易建立验证过程。文本回答也能通过事实核查和人工审阅验证，代码能运行并不表示它自动正确。
前面的四种用法对应同一个设计取向：将可计算的过程交给代码执行，将确定性规则写成可校验条件，并让脚本补足临时集成和展示需求。设计 Agent 时，提供可执行、可校验、可回滚的环境，往往比继续增加提示词措辞更有实际作用。
