线束工程：让智能体真正完成工作的七层环境架构
你的智能体失败了。
你打开提示词，加了一条规则。
它换了个方式失败。你又加一条规则。
三周后，你的系统提示词成了一篇 900 词的「疤痕组织」，你换过两次模型，而智能体依然无法独立完成一个两小时的任务。
那些规则里的大多数，从来就不是解药。因为那些失败里的大多数，从来就不是推理能力的锅。
提示词是你唯一看得见的层，于是它成了你唯一会去改的层。
而真正的缺陷在别处：智能体能看见什么、被允许碰什么、记住了什么、什么才算完成。
那一层有个名字，叫线束（harness）。
线束工程，就是构建那套能把模型智能转化为可信任工作的环境的实践。
提示词改变一次运行。
线束改变之后的每一次运行。
第一部分：先诊断，再打补丁
先给失败命名。几乎每种失败都落在六个桶里：
| 表面现象 | 真正缺失的 |
|---|---|
| 改错了文件，漏掉了对的那个 | 上下文 |
| 在错误的位置跑了正确的命令 | 工具网关 |
| 忘了四十分钟前做的决定 | 持久状态 |
| 什么都没跑就宣布成功 | 证据 |
| 部署了本该由人批准的东西 | 策略 |
| 一模一样的失败调用重试了十一次 | 恢复机制 |
这张表里没有一条写着「模型不够聪明」。
把更强的模型扔进同一个坏掉的环境，你只会得到一个更雄辩地犯同样错误的模型。
没有结构的能力，只是失败得更流利而已。
第二部分：模型只是一个组件
模型会推理、比较、选择。
而智能体要的是「运营」：找到重点、选对工具、真实改变什么、追踪变化、遵守边界、检查结果、错了能回退。
模型是发动机。线束是车身的其余部分。
一台强引擎如果不装底盘，它不是一辆快车，是一个危险品。
线束并不能消除模型的不确定性——没什么能做到这一点。它做的是把不确定性装进一个能观察它、验证它、并把它拉回来的系统里。
七层结构各司其职，每层关掉上面表格里的一种失败。
第三层契约：把愿望编译成合同
大多数智能体任务始于一个愿望：
「把退款积压清掉。」
两个人之间共享上下文时这没问题。但对自主执行来说毫无用处：没有成功的定义，也没有「过头」的定义。
让智能体动手之前，先把意图编译成一份契约：
objective: 清理超过 7 天的退款积压
scope:
- services/refunds
- 退款分析事件
constraints:
- 不碰支付服务商客户端
- 不做 schema 变更
acceptance:
- 本地回放中队列 p95 年龄低于 48 小时
- 退款回归测试套件全绿
- 端到端追踪一笔退款
approval_required:
- 任何生产写入
- 任何面向客户的消息
一个小文件，一个完全不同的问题。
没有它，智能体优化的是「看起来很忙」。有了它，智能体优化的是可检验的目标。
契约也是唯一诚实的失败方式。如果成功从未被定义，「做完了」就只是一种情绪。
第四层上下文：给地图，别给说明书
把整个代码库、全部文档和完整历史塞进上下文窗口，不叫上下文工程，叫洪水灌溉。
那条真正要紧的一行字，依然淹没在四百条不要紧的里面。
给一张地图，让智能体按需拉取细节：
## 项目地图
退款规则 -> docs/refunds.md
服务代码 -> services/refunds/
分析事件 -> packages/events/
测试命令 -> docs/testing.md
发布规则 -> docs/release.md
任务，然后地图，然后子系统，然后具体文件，然后局部规则。
上下文应该因为任务需要而扩张，而不是因为数据存在而扩张。
你优化的不是上下文总量，而是每 token 的信号密度。
第五层工具：要网关，不要工具堆
二十个工具不是二十种能力，而是二十种出错方式，外加每一步的选择难题。
每个工具都该有一份契约，像一个 API 端点：
TOOL: edit_file
inputs: path, patch
preconditions: 路径存在
路径在工作区内
路径不是生成代码
success: 补丁已应用，返回 diff
failure: 不做部分写入，返回结构化错误
risk class: 可回退
然后在所有工具前面放一个网关。
它负责校验参数、隐藏无关工具、限制路径和域名、设置超时、让重试幂等，并且返回证据而不是「成功」这个词。
真正要紧的职责分离：
- 模型提出意图
- 网关授权动作
- 工具改变环境
- 传感器报告结果
模型有发言权，但没有最终拍板权。
第六层记忆：从事务日志到状态
一份对话记录不是记忆，它是事件日志。
作为执行基底很糟糕：关键的那行和随手一提的那行，长得一模一样。
把日志编译成四个桶，从这四个桶上跑任务：
facts:
- 退款资格判定在 services/refunds/policy.ts
- 分析管道会丢弃超过 4KB 的事件
decisions:
- 复用现有资格检查
- 原因：第二份事实来源曾引发上次事故
progress:
done: [按账龄拆分队列]
blocked: [预演环境回放需要新数据集]
left: [部分退款的回归测试]
lessons:
- 测试运行器需要 TEST_DB_URL，否则会静默通过
原始日志留着审计用。执行从编译后的状态出发。
这也是获得「可恢复智能体」的方法：
一个死在第 14 步的运行，从状态重启，而不是从一段没人想重读的对话重启。
把三个关注点物理分离：大脑做规划，双手在沙箱里执行，历史活过上下文窗口。分离之后，你可以换掉任何一个而不重建另外两个。
第七层策略：红线不靠模型自觉
有些规则绝不能依赖模型「记得」：
- 永远不在没有批准的情况下发布
- 永远不写工作区之外
- 永远不暴露凭据
- 永远不超出花费上限
- 永远不在测试没跑的情况下标记通过
这些不是指令。指令只是建议。
这是策略，策略属于代码，由网关强制执行。
按后果分级：
读取、搜索、检查：自动放行。
可回退变更：自动放行，但留痕。
外部影响（发送、部署、花钱）：显式批准。
不可逆或敏感（删数据、轮换密钥）：硬门禁，或干脆不暴露。
自主不是没有限制。
自主是在真正被强制执行的边界之内，跑出速度。
第八层完成：证据，不是声明
「任务完成」不是一种状态，它是又一个 token 预测。
完成是环境的属性，只有环境能授予它：
| 声明 | 证据 |
|---|---|
| 「bug 修好了」 | 那个失败的测试现在通过了 |
| 「流程没问题」 | 一个真实会话完整走通了它 |
| 「迁移是安全的」 | 演练和回滚都通过 |
| 「数字是对的」 | 输出与源数据对得上 |
| 「任务完成了」 | 每条验收标准都通过 |
最便宜的确定性检查优先：语法、类型、聚焦测试、集成，然后才是判断力，最后是人。
永远不要在编译器、schema、校验和或一条 SQL 查询能回答问题的地方，花一次模型调用。
模糊性问题交给模型。管道问题交给代码。
验证是一种攻击
让同一个智能体在同一个上下文里自查，它会重新推导自己的假设。
那不叫验证，叫信心回路。
把目标拆开：工人构建最强候选方案，验证者尽力搞坏它。
给验证者一份拒绝评分标准、产物、契约和全新上下文。
还要给它「拒绝但不必修复」的权利。
最后这条很关键。一个必须顺手修复的验证者，会悄悄把标准降低到自己会修的水平。
第九层恢复：对症下药
默认恢复策略通常是：什么东西坏了，再跑一遍。
那不叫恢复，那是一台带 API 账单的老虎机。
先分类，再响应：
工具超时 -> 退避后重试
参数非法 -> 修复调用
上下文缺失 -> 检索特定来源
测试失败 -> 检查具体行为
权限拒绝 -> 请求批准或走安全路径
约束互相矛盾 -> 上报人工
同样的失败原样复发 -> 停
底层规则：每次重试必须至少改变一个相关条件。
否则你是在花钱复现一个已知结果。
每个循环都要有预算：最大尝试次数、最长耗时、最大花费、最大破坏范围，以及一个升级触发器。
可靠的智能体知道怎么继续。
优秀的智能体知道什么时候继续下去已经不理性了。
第三部分之后：让运行可读
一个干净的回答可以藏着一个丑陋的过程。
智能体可能读错了数据、忽略了一条失败的命令、把外部 API 调了两次、烧掉十倍预算，然后碰巧对一个下周就不再成立的理由给出正确结果。
你要的是一条能让运行可复现的轨迹：
09:14 契约创建
09:15 上下文加载: docs/refunds.md
09:17 编辑 services/refunds/queue.ts
09:18 聚焦测试失败: 部分退款重复计数
09:21 修复已应用
09:22 聚焦测试通过
09:24 集成套件通过
09:25 部署被阻断: 需要批准
记录状态迁移、上下文来源、工具输入输出、验证结果、重试原因、批准、成本、延迟。
这不是监控，这是「在第 14 步重启」和「从零重启」的区别。
交付收据，不是对话
没人会审查四百轮智能体 chatter。一次运行结束时，编译出这样一张表：
| 字段 | 值 |
|---|---|
| 目标 | 清理超过 7 天的退款积压 |
| 变更 | 队列拆分逻辑，一个回归测试 |
| 已验证 | lint、单元、退款集成套件 |
| 未验证 | 生产支付服务商、旧移动客户端 |
| 决策 | 保留现有资格检查作为唯一事实来源 |
| 风险 | 预演回放用的是三周前的数据集 |
| 待批准 | 部署到预演环境 |
收据不是模型说了什么的摘要。
它是系统能证明什么的摘要。
最好的交接从来不是「给你看对话」，而是「给你看状态、证据和未解决的风险」。
飞轮，然后是修剪
弱队修坏掉的产出。强队修让产出坏掉的那个东西。
每次失败后跑一遍诊断：
契约是否含糊？上下文是否不可见？是否暴露了错误的工具？是否缺了前置条件？结果是否无法验证？策略是否活在提示词里？恢复是否太粗？轨迹是否太薄？
然后沿着这架梯子往下沉淀教训：
解释 → 检查清单 → 模板 → 自动化检查 → 强制策略
「记得用格式化工具」变成一个自动运行的格式化工具。
「不要跨层 import」变成一个架构测试。
提示词承载判断力，线束承载不变量。
修正一个答案，帮到一次运行。修正一个线束，帮到之后的每一次运行。
然后删掉一半
线束会腐烂，没人写这部分。
你去年为绕过上下文限制搭的便道，现在挡着更好的策略。
某个糟糕一周后加的重试规则，现在给每次调用平添四秒延迟，而那个故障三月起就没再出现过。
把线束组件当生产代码对待，衡量它们是否还挣得回成本。对每个路由器、评估器、记忆层和重试规则问四个问题：
- 它防止哪种失败？
- 那种失败现在还发生吗？
- 它增加了多少延迟和复杂度？
- 删掉它会坏什么？
最好的线束不是最大的那个。
它是最小的、能可靠弥合「意图」与「证据」之间鸿沟的系统。
为删除而构建。
构建顺序
你不需要一个编排平台。你需要一次加一层，每层都加在你真实见过的失败之后。
- 一个有边界的任务：目标、范围、约束、验收。
- 一个可读的环境：地图、命令、局部规则、依赖。
- 受控的动作：类型化工具、校验、路径限制、结构化结果。
- 持久的执行：显式状态、检查点、决策、教训。
- 证据：确定性检查、对抗性验证、收据。
- 恢复与学习：失败分类、有限重试、升级、线束更新。
不要因为一个提示词偶尔需要澄清就上多智能体架构。
复杂度是由观察到的失败挣来的，不是提前预支的。
规格表
授予真实自主权之前，把这张表填满：
- 契约：目标、范围、约束、验收证据
- 上下文：常驻地图、检索来源、新鲜度规则
- 工具：允许集、前置条件、副作用、超时
- 状态：事实、决策、进度、教训、检查点
- 策略：自动、需批准、禁止、预算上限
- 验证：确定性检查、对抗性检查、验收
- 恢复：失败分类、重试上限、升级、回滚
- 可观测性：轨迹事件、指标、最终收据
空着的字段，意味着智能体并不自主。
它正拿着你的凭据在即兴表演。
衡量对的东西
Token 数不是指标，「尝试过的任务数」也不是。单位是被接受的工作：
被接受的产出
--------------------------------------------
人工审查分钟数 + 单次运行成本
同时跟踪一次通过率、工具故障后的恢复率、重复失败率、每任务人工干预次数、以及无依据的完成声明数。
这能杀死一种特定幻觉：一个智能体可以看起来极其高效，同时在为人制造昂贵的审查工作。
活跃不等于产出。
什么时候不需要这些
不是每次模型调用都需要一个操作系统。
任务短、输出好扫一眼、失败便宜、没有外部状态改变、而且你在旁边看着——用普通提示词就好。
当工作跨工具或跨会话、环境在变、动作有后果、完成与否难以靠阅读判断、同样的失败反复出现、或审查成了瓶颈——那就构建线束。
范式转移
第一代 AI 产品围绕提示词构建。
下一代围绕环境构建。
问题不再是「怎么得到一个更好的回答」。
而是：怎么构建一个系统，让好的动作容易做、危险的动作被门禁拦住、失败看得见、完成可证明。
模型提供智能。线束提供结构。
可靠性住在后者里。
如果你的智能体总是散架，别再往提示词里堆形容词了。
去构建它成功所需的环境。
原文信息
作者：spectnfa（@spectnfa） 原文地址：
暂无评论，快来抢沙发～