生产级 Harness：从样机到工坊规矩
引言
钟表匠做出第一座样钟时，镇上的人围着它鼓掌。那座钟只要今天响一次，就算成功。
第二年，镇上要给每条街装钟。问题变了：谁记录每座钟的图纸，谁保管零件，某个零件批次出问题怎样召回，换一个工匠会不会把旧规矩打乱，新钟能不能先装在一条街试运行，再推广到全城。
老钟表匠把工具放下，开始写工坊规矩。学徒问："这还是修钟吗？"
他说："样钟靠手艺，工坊靠制度。"
生产级 Harness 要做的，就是把能跑的原型变成能长期运行的工坊。
TL;DR
从原型到生产，Harness 要补上四类工程能力：系统提示词的模块化和缓存，插件与技能的扩展体系，token、延迟和成本治理，配置、特性门控与灰度发布。成熟度不看控制有多少，而看每个控制是否有明确理由，是否能随着模型能力变化被保留、调整或删除。
1. 系统提示词是工程资产
系统提示词不只是角色设定。它定义 Agent 的身份、工具使用方式、交互规则和安全边界，也直接消耗 token、影响缓存命中和行为稳定性。
生产系统应把提示词按变化频率拆开：
- 核心身份和原则，变化少。
- 能力说明和工具使用规则，相对稳定。
- 领域知识和最佳实践，可版本化。
- 当前任务、用户约束和最近状态，每轮变化。
稳定内容放在前缀，动态内容放在末尾，才能利用提示缓存。缓存命中依赖字节一致，多一个空格都可能失效，所以可缓存模块要像代码一样版本管理。
提示词越长不代表系统越可靠。只应该放删掉后会明显出错的规则。泛泛的"仔细检查"会浪费窗口，具体的"写文件前确认目标路径在工作区内"才有工程价值。
2. 扩展体系要低耦合
原型加功能常常直接改核心代码。生产系统要支持插件、技能、钩子和命令，把扩展能力从主流程里拆出来。
插件是可加载的模块包，带元数据、版本和权限声明。技能是可复用的工作方法或原子能力。钩子插在模型解析前、工具调用前、任务结束后等关键位置。命令是用户触发能力的入口。
权限也应声明化。低风险查询可以自由执行，中风险操作首次询问，高风险副作用必须审批。插件把权限写进清单，审计系统才能回答谁引入了什么能力、这项能力能做什么。
技能还可以成为可维护的知识资产。团队可以收集任务轨迹，找出哪些技能规则帮助了成功、哪些规则导致失败，再小步编辑、跑验证集、保留有效变更。这样技能不再是一份静态说明，而是可评估、可回滚的过程性知识。
3. 成本和延迟要进入控制面
生产 Harness 的成本大多花在上下文和模型调用上。控制成本不能只靠"少用模型"，还要治理上下文本身。
几类杠杆可以叠加：
- 前缀缓存复用稳定系统提示和工具定义。
- Schema 缓存减少重复发现工具的开销。
- 结果缓存避免重复查询低变化数据。
- 上下文压缩清理长会话里的冗余工具输出。
- 多模型路由把简单任务交给便宜模型，把复杂任务交给强模型。
延迟治理也要分层。流式响应降低首字等待，并发工具调用减少互不依赖任务的总时长，多级缓存减少重复计算，托管 Agent 可以把模型循环和执行沙箱解耦，让不需要沙箱的会话更快开始。
预算要按单次请求、单个任务和系统周期管理。接近阈值时，系统要降级、压缩、换模型或停止，而不是等账单失控后再查日志。
4. 发布要能灰度和回滚
生产系统的配置不能硬编码。环境变量适合 secrets 和最高优先级覆盖，项目配置适合业务差异，全局配置适合默认值。API Key 和凭据只走环境变量或密钥管理，不能进入仓库配置文件。
特性门控把新功能从"一次性上线"变成"可控放量"。编译时门控适合构建期就确定的功能，运行时门控适合灰度、A/B 测试和按用户分组发布。
金丝雀发布要配自动回滚条件。先给少量流量，观察错误率、延迟、成本和用户反馈，稳定后再放大比例。每个阶段都要有停止线。上线不是勇气测试，它是带观测的实验。
5. 控制也要定期审计
生产化容易把系统越包越厚：缓存、压缩、重试、校验、审批、灰度、回滚。它们都可能有价值，但每一层都编码了一个假设：模型或环境自己做不好这件事。
模型能力变强后，一些控制会过期。替模型擦屁股的控制，比如格式清洗、过度重试、机械化自检，可能可以收缩。守住不可逆副作用的控制，比如权限、提交边界、审计、回滚，不能因为模型变强就省掉。
真正成熟的生产系统，会持续问：这个控制上次真正救场是什么时候，它花了多少成本，删掉会不会放大爆炸半径。
写在最后
工坊越做越大后，老钟表匠每年都会烧掉一批旧规矩。不是因为规矩没用，而是有些规矩只适合第一批学徒。
但他从不烧三本账：仓库钥匙账、出厂检验账、返工记录账。
他说："手艺变好，可以少写几条提醒。钟要交到别人手上，就不能少留证据。"
生产级 Harness 也要有这种判断。能优化的地方大胆优化，能简化的地方定期简化；但权限、预算、灰度、审计和回滚守的是系统边界，不能靠模型变聪明来替代。原型证明它能跑，生产系统证明它能在变化中继续跑。