曹辉认为Harness Engineering比模型本身更值得关注。大模型能力正逐渐趋同，未来的技术壁垒正在从模型本身转向Harness Engineering。他总结了若干设计原则：状态落盘而非驻留内存、生成与评估分离、机械强制优于文本规劝、Auto-Dream机制、多智能体协同等。核心思想是把不可控的大模型装进可控的工程框架里。
北京研发中心的同事引用了LangChain的定义：Agent = Model + Harness。Harness是模型之外的一切代码、配置与执行逻辑，相当于一个运行时系统，将模型的原始能力转化为稳定、可控、可用的工作引擎。他拆解了Harness的几个核心组件：工具集成、上下文工程、状态持久化、子代理编排、安全防护、可观测性。每一块都不算新，但组合成一个系统才是难点。他提到了几个行业案例的细节：Anthropic通过三阶段架构与评估智能体解决了上下文割裂和模型“自我感觉良好”的问题；OpenAI的“动态地图”实现了百万行代码的自动化生产；LangChain构建了验证闭环、设置主动退出机制与算力分级，大幅提升模型性能。另一个设计叫做“推理算力三明治”：在任务规划和最终验收阶段使用最高等级的推理能力；中间执行阶段使用低等级推理甚至不进行推理。这样既节省Token，又不影响效果。
成都研发中心的同事分享了一个实打实的落地案例。他们团队面对的问题是数据中台平台里Sonar检测出大量代码问题，涵盖不同优先级。同时，测试覆盖率和代码重复率都未达到标准。这些问题让人专门去修，成本高且枯燥，于是他们尝试用AI实现全自动闭环修复。团队借鉴了Cursor等产品的Master-Worker架构，搭建了一套自动化Bug修复系统。每个Worker的工作流程是：拉代码 → 分析Sonar issue → 执行修改 → 跑测试 → 提交代码。整个系统与GitLab代码仓库打通，并配有监控面板，可以实时查看任务进度和成功率。实践中发现，在有强验证机制的前提下，小模型也能胜任复杂任务。对比测试显示：加上Claude Code工程框架后，修复成功率从26.3%提升到40.4%——这部分提升完全来自工程能力。截至分享时，这个系统已经处理了300多个issue，修复准确率约80%。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/260230.html