把前沿模型扔进糟糕设计的智能体系统你只会得到更会说话的失败把最强的前沿模型塞进一个设计糟糕的智能体系统结果往往不是能力跃升而是失败变得更会说话、更难排查。几乎所有真正的工程量都落在模型之外——那个被称作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和系统实验。感兴趣可以关注我们下期见。