智能体工作流设计

GitHub 把 Copilot 代码审查的专用代码探索工具，换成了维护得更好的共享 CLI 工具。预期是一次干净的升级，结果基准显示审查成本更高、抓到的问题更少。真正翻转局面的不是再换一次工具，而是按「审查者实际怎么读一个 PR」重写工作流指令——之后成本降低约 20%、质量不变。

这件事定义了这项技能：决定一个智能体好不好用的，是流程的形状，不是它手里有几件工具。

先把智能体拆成能各自演进的几层

Ai2 的 Shippy 服务 70 多个国家的分析人员做高风险判断，它的拆法值得直接借用：

1. soul——定义边界的系统提示：它是谁、不做什么。
2. skills——用 markdown 文档化的能力，一件事一份。
3. config——运行时配置。

三层各自独立版本化，改一层不必重建整体。这个拆法之所以有用，是因为它把三种变更频率完全不同的东西分开了：边界很少改，能力经常加，配置每次部署都可能变。混在一个大提示词里，就意味着每次加一个能力都在动边界。

每一步都要有明确的交接点

一条工作流是由交接点定义的，而不是由步骤数量。每一步动笔之前先答三个问题：

• 这一步收到什么——上一步保证交付的是什么形状。
• 这一步必须产出什么——下一步会依赖的是什么。
• 谁来判断它做完了——外部状态、人写的检查，还是模型自己。

第三问最容易被跳过，而它是长链路失败的主要来源，展开在「完成判定与验收信号」。

护栏要放在能拦住的位置

护栏写在提示词里，只能约束模型的意图；真正拦得住的是执行路径上的硬约束——权限范围、可调用的工具集合、沙箱边界。Shippy 按用户会话分配独立的 Kubernetes 沙箱，在数百个政府合作方之间做数据隔离，是这条的极端形态。

判断护栏是否真的存在，只问一句：模型如果决定越界，是什么在物理上阻止它？ 答案如果是「提示词里写了不要这样做」，那就是没有护栏。

自己搭 runtime，还是用平台托管

这条边界最近一年被推着走了很远。Gemini 的 Managed Agents 把执行环境、状态管理、工具接入都收到平台侧：传一个 background:true 就能让长任务异步跑在服务端，客户端凭 ID 轮询或断线重连；Ollama 则从「把开源模型跑在本地的运行时」转向「智能体工作的入口」。

所以这不再是一个技术选择，而是一个所有权选择：你必须自己拥有哪一层。 长任务的状态管理和沙箱是自建里最贵的两块，也是平台最先补齐的两块。

与相邻能力的分工

这一条管整条链路的形状：怎么分层、怎么交接、护栏放在哪。单个工具怎么接得可维护，是「工具集成模式」；对抗性输入怎么防，是「智能体安全与提示注入防御」；任务跑完之后怎么回放和归因，是「智能体可观测性与评测运维」；而「你要拥有哪一层」这个决定本身，是「AI 工具链选型与自建边界评估」。