Harness Engineering 构建AI可控运行环境。过去一个月，拓尔思内部密集举办了五场以AI为主题的工程技术分享，包括OpenClaw、Claude Code、“效率革命”、“金析为证”和Palantir。在技术快速迭代的当下，高频次的知识对齐已成为构建敏捷型学习组织、缩短从认知到工程落地之间距离的必要策略。

第六场内部技术沙龙聚焦于Harness Engineering，其核心是为AI Agent构建一套完整的运行环境、约束规则与反馈闭环，使AI能够可靠、自主地完成复杂工作。

拓尔思副总裁曹辉讨论了CLI（命令行界面）在AI时代重新受到关注的原因。他指出，在ToB业务场景下，企业无法依赖大厂的云端工具，CLI能够完美适配本地执行的需求。当前的CLI是一种“外壳为LUI，内核为CLI”的最优工程混合体，LUI意图层采用自然语言交互，用户只需表达“做什么”，CLI执行层则通过调用本地命令、操控浏览器、读写文件系统等方式完成具体操作。这一设计的目标是“剥离中间层，直接触达万物”。曹辉以MCP为例说明：MCP旨在让AI触达各类系统，但落地时受限于厂商是否开放API。而CLI模式，特别是通过控制浏览器，Agent可以模拟人类操作任何B/S架构的业务系统，不依赖厂商配合。

曹辉分享了一个实际案例：通过Codex的APP版本，指令一个AI Agent从GitHub下载OpenCLI项目并进行全面分析。该Agent自主完成了拉取代码、解决依赖、构建沙箱环境等任务，在遇到本地缺失工具或需要决策时主动向用户请示，最终生成了一份多维度研究报告。整个过程几乎不需要人工干预。对企业来说，这意味着端侧执行是成本与效率的必然选择。他提出了“云端慢思考，端侧快执行”的架构：云端负责复杂推理和大规模知识检索，端侧负责轻量级执行、本地资源调度和实时响应。

曹辉认为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%。

数字经济研究院同事把Agent落地中遇到的常见问题归纳为失忆、流程失控、作恶/欺骗三类。对应这三类问题，他提出了三层解法：上下文与记忆管理、流程与编排控制、验证与护栏。他介绍了数研院的两个产品实践：SurgeFlow和SurgePix。他认为，CLI的核心优势不是“命令行”本身，而是可组合性——Agent可以把多个原子命令像搭积木一样组合成新功能，而API很难做到这一点。

成都研发中心的另一位同事带来了拓尔思技能库建设中的一线经验。团队从实际问题出发，逐步总结出六条核心原则：避免AI自我评估、限制重试次数、使用Checklist管理状态、不默认AI已知任何未明确告知的信息、确保每一步可观测、以上条件满足后，AI才能一次输出可用的Skill。

六位同事的接力分享，从不同角度指向同一个结论：大模型的能力正在趋同，真正的护城河正在向Harness Engineering转移。分享尾声，曹辉向内部团队提出了明确的技术演进要求：拓尔思的智能底座必须加速完成Harness能力的工程化封装，让前线业务能感知到工程约束带来的稳定性跃迁。这条路没有捷径，但每一步的积累都会沉淀为组织真正可控的生产力。对于拓尔思而言，这正是将“驾驭工程”写入技术基因的起点。