把前沿模型扔进糟糕设计的智能体系统你只会得到更会说话的失败
把最强的前沿模型塞进一个设计糟糕的智能体系统，结果往往不是能力跃升，而是失败变得更会说话、更难排查。几乎所有真正的工程量都落在模型之外——那个被称作Agent Harness的脚手架上。工具、提示、记忆、编排，以及人在回路中的位置，这五块你要么主动设计，要么默认设计，没有中间状态。
我起初以为换一个更强的模型就能解决问题，后来在真实生产系统里反复踩坑才发现：模型只是执行器，真正决定系统是否稳健的是围绕它的一切。DevVoice就是一个活生生的例子——一个五智能体流水线，把GitHub README变成经过审核的X线程、LinkedIn帖子和dev.to文章。下面所有设计决策都来自这套系统，而不是纸上谈兵。
智能体工作负载和Web请求从根上就不是一类东西
典型Web请求只要50到200毫秒，CPU突发占用，结果确定，单次成本几乎为零。智能体任务完全相反：耗时长、I/O密集、结果非确定、边际成本高到可以每分钟烧掉一美元。
这直接带来四条架构后果。你无法同步回答请求——负载均衡有空闲超时，把连接挂两分钟纯属浪费。并发瓶颈不在核心数，一个2核容器就能跑几十个并发任务，因为70%到80%的时间都在等模型API。同样输入会产生不同输出，重试不是免费的，CI里没法对最终结果做断言，测试必须对准Harness而不是模型。一个无限循环会在你睡觉时默默烧钱。
从第一行代码就按这个形状设计，部署只是配置；按Web形状设计，部署就是重写。
你真正要设计的五块Harness组件
工具是智能体影响世界的唯一接口。设计得差，模型就在困惑里浪费token；设计得好，上下文能砍掉60%。
工具定义就是一份契约：输入输出必须类型化，模型看到的是schema，模糊会直接变成错误和多余token。用Pydantic这类模型约束复杂返回。表面要小，一个工具只做一件事，五个聚焦工具远胜一个带五个可选参数的大杂烩。工具必须确定且快，超过30秒的操作会杀死上下文，要么做成异步加状态查询，要么扔进任务队列。
把工具放进统一注册表，而不是散落在智能体代码里。工具和智能体分开版本：有的还在用search_v1，有的已经切到search_v2。每次调用都记参数和延迟，一半的问题都会从这里暴露。给每个工具加超时，挂死的工具会拖垮整个智能体。
提示不是散文，是状态机。结构比措辞更重要。铁律是静态内容永远在动态内容前面：工具定义、系统提示、示例、历史、最后才是用户轮次。任何动态值往上泄漏，都会击穿提示缓存，悄悄把token成本翻倍。提示要版本化，响应缓存的key也要跟着版本走，修完一个坏提示后旧缓存还能继续服务好几个小时。
记忆分两种，不能混用。工作记忆是短期、在上下文里的：当前轮次、最近N条消息、本次任务检索到的上下文，预算就是上下文窗口能塞下的量。持久记忆是长期、存储支撑的：用户偏好、历史学习到的事实、评估结果和失败记录，可以无限期保存。把“记住X”每次都塞进系统提示，只会白白烧token。正确做法是工作记忆智能截断（丢最老、留最近和最相关），长对话存摘要到持久层，文档按章节边界切分而不是死卡token数。
多智能体编排有并行和顺序两种。并行听起来高效，实际制造协调噩梦：A的输出是B需要的，但两者速度不同，最后变成轮询和合并。顺序子智能体更干净：数据流明确、可提前退出、状态单向传递、调试简单。只有真正独立、结果互不干扰的场景才用并行。每个子智能体进程内建一次、调用多次，状态按顺序流过。
人在回路不是为了“重要”才介入，而是为了“不可逆”。测试标准很机械：另一次工具调用能不能撤销？读取、检索、起草可以错，下一步能修；发布、发送、删除、花钱不行。过度设门会训练审核人机械点批准，既付了延迟又丢了安全。门要稀少才有意义。门是运行停靠的状态，而不是阻塞调用。
循环工程是一个节点一个目标、一个验证器、一个停止条件。图工程是这些循环之间的拓扑：哪些节点存在、哪些转移合法、状态怎么跨边。从循环起步，只有当某个决策失败代价高到必须“不可能”而不是“不太可能”时，才把它挪进图。停止条件至少四个：模型自己的判断、步数预算、墙钟预算、token预算。模型只拥有一个出口，你拥有另外三个。一个不再进步的循环不会报错，每次调用都成功，却每分钟继续烧钱。
评估框架必须先于智能体本身设计
智能体系统产出的结果看起来合理，却经常出错。你没法在CI里测正确性，必须有一套质量评估、回归捕获和变体对比的框架。
三层评估缺一不可。第一层是Harness正确性：编排是否按预期走、工具是否返回正确schema、状态是否正确转移、结果是否正确组装——这些可以确定性测、放进CI。第二层是智能体输出质量：是否符合规格、事实是否准确、推理是否扎实、格式是否正确——用采样方式做。第三层是端到端回归：每周固定测试集跑一遍，用裁判模型对比基线，回归进生产前就抓住。
标准指标覆盖编排层（成功率、延迟、重试率）、输出质量（裁判分数、事实准确率）、成本效率（每任务token、每任务美元）。用另一个LLM当裁判，给它明确的评分标准，产出结构化结果。每天抽样100到200个任务打分，P50分数掉出基线一个标准差就告警。用同一组测试用例跑A/B两个版本，直接比较裁判分数。裁判本身也要测：已知好坏样本能否区分、边界案例是否一致、是否与人类评分相关。
每周评估跑、A/B对比、失败模式回流进测试集，形成闭环。
| 组件 | 默认做法带来的风险 | 主动设计后的收益 |
|---|---|---|
| 工具 | 表面过大、无类型、无超时 | 上下文砍半、错误可定位、成本可控 |
| 提示 | 动态内容前置、无版本 | 缓存命中率高、回滚只需改环境变量 |
| 记忆 | 工作与持久混用、每轮重发 | token浪费消失、长期知识真正积累 |
| 编排 | 盲目并行、状态乱合并 | 数据流清晰、可提前退出、调试简单 |
| 人在回路 | 按重要性设门、门太密 | 真正不可逆才拦截、审核注意力保持有效 |
| 停止条件 | 只靠模型自己说结束 | 四重保险、烧钱循环被提前掐断 |
| 评估 | 只测模型、生产才发现问题 | 回归在进生产前就暴露 |
这套清单里几乎没有模型本身的位置。换掉底层模型，八条原则依然成立。这才是真正的工程，而不是模型周围的管道。
把Harness当成系统真正的主体，而不是模型的附属品，是区分“能跑演示”和“能扛生产”的分界线。模型可以每周换，Harness一旦设计对了，就能跟着业务一起长。
你准备从工具契约还是停止条件开始，给自己现有的智能体系统补上第一块真正的工程骨架？
我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。
