https://segmentfault.com/a/1190000048153203 看看这个

回复 群友 8384： 看完了，这篇《一个好的 Harness，会吃掉定制 AI Agent 吗？》，作者是零一万物的马诺，整理自 Community over Code Asia 2026 的演讲。核心一句话概括就是：harness 吃得掉胶水层，吃不掉领域的真相和责任的边界。 它的推理链条挺清楚。先拿 Deep Research 当标本：这个品类被吃掉，是因为凑齐了三个属性——工具全是通用的（搜索、浏览、跑代码、沙箱，没有私有环节）、产出只是一份报告（不改动任何业务系统，基本不产生后果）、验证靠人扫一眼。三条凑齐，定制空间就没了。然后顺手给那些精巧的 agent 框架判了个刑：外置规划、外置记忆、外置反思，本质是对模型弱点的补偿，补偿型脚手架代码的半衰期约等于一代模型。 真正有意思的是它给的那把尺子：一个动作越容易验证、越容易回滚，harness 吃得越多。光谱从左到右是「改代码跑测试」→「探索性报告」→「业务数据的判断」→「写入业务系统」。吃到「不可逆加高代价」就停，停的原因不是能力不够，而是谁能替最终结果负责。 后面那个「两个平面夹一个领域核」的架构表述，我个人觉得对做企业 agent 的人有参考价值：认知平面（探索 schema、生成候选规则、收集证据）交给 harness；领域核（实体与字段模型、权威度、校验规则、血缘、访问控制、置信度校准）自己做，原则是「把领域里什么是对的，从 prompt 里搬出来，落成代码、数据和服务」；事务平面确定性且受治理，agent 不直接改业务记录，只产出带证据、置信度和回滚方案的变更提案，由确定性服务去校验和写入。 有两点值得拎出来说一下。一是它对 skill 的判断：skill 是建议不是约束，规则 98% 会被照做——对报告够用，对不可逆写入，剩下那 2% 就是事故率。这个说法跟群里之前聊垂直 Agent 壁垒时的结论是对上的，Skill 文件本身没有护城河，真正难抄的是评测集和契约。二是结尾那句反问挺狠：能被现场发明的都会被现场发明，剩下不许现场发明的，才是你的架构。 唯一我觉得可以商榷的是它把 harness 和模型厂的 co-design 说得比较必然，但这属于立场判断，不算事实错误。整体上是一篇写得挺扎实的架构反思，尤其适合正在纠结「该自建 agent 框架还是直接用 Claude Code」这个问题的场景。