代码怎样成为 Agent 的元能力
一句话收获：代码扩展 Agent 能力，也扩大执行风险，因此必须隔离和验证。
这个场景在解决什么问题
Agent 不只是"说话"，它还能让代码成为自己的能力——AI 生成一段代码，帮它做计算、连接口、甚至沉淀成可复用的能力。但"代码"是把双刃剑：它能扩展能力，也能扩大执行风险（乱写文件、越权、埋雷）。
这个场景的目标（goal）是：区分临时计算、接口适配和候选能力形成。观察点（observation）是：同一段 AI 生成代码经历三种使用方式——同一段代码，可能只是临时算个数、可能是连个接口的适配器、也可能变成候选能力，三种用法的风险等级完全不同。
它值得单独学，因为它提醒你：代码一旦进 Agent，就不再是"聊聊天"，而是"真的在执行"，所以必须隔离和验证，不能让它裸奔。
先理清这条判断链（文字版）
同一段代码，按风险从小到大、沉淀从浅到深，有三种用法，是一条递进链：
- 先看临时计算——在沙箱里生成数据转换、一致性检查代码，确定性计算比自然语言估算稳，但输入和公式仍要验收。
- 再看接口适配——Coding Agent 生成适配器连现有内部 API，契约、权限、错误都要继承，不能借适配扩大权限。
- 然后看候选能力——重复任务触发"候选实现 + 测试 + 说明"的生成，可复用能力要脱离当前对话，先进入候选区。
- 最后看第二任务验证——用不同输入和局部环境复用候选，检查隐藏依赖，暴露过拟合和硬编码。
逐层详解
第 1 步：临时计算
原文：Agent 在沙箱中生成数据转换和一致性检查代码。
白话：Agent 遇到需要"精确计算"的事（比如数据格式转换、数据一致性核对），就在沙箱（隔离的受控执行环境）里现生成一段代码来算，算完用完就扔。
类比：像在计算器上现敲一个公式算个数，算完就不留了——不存进系统、不影响别的地方，纯粹是"临时用一下"。
举例：Agent 拿到一份 Excel 导出的订单数据，要核对"总金额是否等于明细之和"，它在沙箱里生成一段转换+校验代码，跑一下确认数据一致，用完即弃。
为什么重要：确定性计算比自然语言估算更稳定。让模型用嘴去"估"一笔账，容易错；让它生成代码去"算"，是确定性的，结果更稳、可复现。
怎么验证（证据点）：
- 输入范围明确：代码处理的输入范围是清楚的。
- 沙箱执行：代码是在沙箱里跑的，不是直接在真实环境裸跑。
- 结果可核对：算出来的结果能再人工或程序核对。
别踩的坑（边界）：由代码计算不证明业务定义正确。代码算得再精确，也只能保证"按你给的公式算对了"，不能保证"这个公式本身符合业务定义"——公式错了，算得再准也是错。
落地检查：输入和公式仍需验收。落地时不能因为"是代码算的"就放心，输入的数据和用的公式本身还要经过验收。
第 2 步：接口适配
原文：Coding Agent 生成适配器连接已有内部 API。
白话：让 Coding Agent 生成一段"适配器"代码，把 Agent 的调用连到公司已有的内部 API 上，让 Agent 能复用稳定的业务能力。
类比：像给两个接口不匹配的设备做一个转接头，让它们能连起来，但转接头不改变两边各自的功能和权限。
举例：Agent 要查订单，Coding Agent 生成一个适配器，把"查订单"这个动作转成对内部订单 API 的调用，复用 API 已有的权限校验和状态规则。
为什么重要：代码可以把稳定业务能力接入 Agent。已有的内部 API 是经过验证的、稳定的业务能力，通过适配器接进来，Agent 就不用自己重新造轮子。
怎么验证（证据点）：
- 契约已知：连的 API 契约（输入输出）是已知的。
- 权限继承：适配器继承原 API 的权限，不新增。
- 错误可转换：API 报错能转换成 Agent 能理解的错误信息。
别踩的坑（边界）：适配成功不允许扩大 API 权限。适配器只是"转接头"，不能借机给 Agent 开更大的权限口子——API 原本允许什么，适配后还是只能允许什么。
落地检查：语义和权限保持一致。落地时要确认：适配前后的语义（这个动作什么意思）和权限（能干什么）都保持一致，没有悄悄变大。
第 3 步：候选能力
原文：重复任务触发候选实现、测试和说明的生成。
白话：当发现某个任务被反复做、有复用价值时，就触发一次"候选能力"的生成——不只是生成实现代码，还要配套生成测试和说明文档，让它成为一个"候选"的正式能力。
类比：像发现某个手工活老是要做，就决定把它做成一个"候选工具"：做工具本体 + 写测试保证它好用 + 写说明书告诉别人怎么用。
举例：Agent 反复要做"把 Excel 转成标准 JSON"这个活，于是触发生成：候选实现代码 + 一组边界测试 + 一份说明（输入输出、依赖）。这套东西先放进候选区。
为什么重要：可复用能力需要脱离当前对话。临时代码是绑在这一次对话里的，换次对话就没了；要变成可复用能力，就得把它从当前对话里抽出来，独立成"实现+测试+说明"。
怎么验证（证据点）：
- 输入输出明确：候选能力的输入输出定义清楚。
- 依赖列出：依赖了哪些库、哪些环境，都列出来了。
- 边界测试：有覆盖边界的测试。
别踩的坑（边界）：运行一次成功不能成为正式 Skill。候选能力跑通一次，只是"能跑"，离"正式 Skill"还差得远——它还没经过准入、验证、注册，不能直接转正。
落地检查：先进入候选区。落地时候选能力先放进一个"候选区"（隔离的暂存区域），等后续验证，不能直接上线成正式能力。
第 4 步：第二任务验证
原文：使用不同输入和局部环境复用候选，检查隐藏依赖。
白话：候选能力不能只验证一次，要拿到"第二个任务"上复用——用不同的输入、放在一个局部的环境里跑，看它有没有偷偷依赖上一次的环境（隐藏依赖）。
类比：像测试一个"通用工具"，不能只在它诞生的那个工位上测，要拿到另一个工位、换种料去试，看它是不是只在老家好使。
举例：候选的"Excel 转 JSON"能力，第一次是在固定路径的文件上测通的；现在换一个不同结构的 Excel、放到一个干净目录里跑，看它会不会因为硬编码了旧路径、旧列名而失败。
为什么重要：第二任务暴露过拟合和硬编码。第一次成功可能只是"过拟合"了那一次的具体情况（写死了路径、列名），换第二个任务就现原形，所以必须用第二个任务来揭穿。
怎么验证（证据点）：
- 新任务通过：换新输入后能通过。
- 失败路径通过：错误/异常路径也能正确处理。
- 无隐藏文件：没有依赖上次遗留的隐藏文件/状态。
别踩的坑（边界）：第二任务通过也需要持续回归。第二个任务通过了，也不代表以后永远稳，还需要持续的回归测试来兜底。
落地检查：能力进入版本化治理。落地时通过了第二任务验证的能力，要进入"版本化治理"——有版本号、有变更记录、有回归集，不能再随意改。
落地可行性小结
本场景涉及的核心技术栈：沙箱（sandbox）、Coding Agent（代码生成）、适配器（adapter）、内部 API、候选区（candidate pool）、边界测试、版本化治理。
真实落地要检查的事：
- 临时计算必须在沙箱里跑，输入范围明确、结果可核对，公式和输入本身仍要验收。
- 适配器只做"转接"，权限和语义必须与原 API 一致，不能借适配扩大权限。
- 候选能力要"实现 + 测试 + 说明"三件套齐备，先入候选区，不直接转正。
- 候选必须过"第二任务验证"，用不同输入和局部环境暴露过拟合、硬编码、隐藏依赖。
常见坑：
- 让 AI 生成代码在真实环境裸跑，没有沙箱隔离。
- 适配器悄悄放大了 API 权限，埋下越权隐患。
- 跑通一次就当成正式 Skill，跳过候选区和验证。
- 没做第二任务验证，硬编码路径/列名的问题没暴露。
回顾
- 代码扩展 Agent 能力，也扩大执行风险，必须隔离和验证，不能裸奔。
- 同一段代码有三种用法：临时计算、接口适配、候选能力，风险等级逐级升高。
- 临时计算靠沙箱隔离，且"算得对"不等于"业务定义对"。
- 候选能力要"实现 + 测试 + 说明"，先入候选区，不能跑通一次就转正。
- 第二任务验证是揭穿过拟合和硬编码的关键，通过后还要持续回归和版本化治理。