来源：市场资讯
（来源：拓尔思）
过去一个月，拓尔思内部密集举办了五场以AI为主题的工程技术分享——OpenClaw、Claude Code、“效率革命”、“金析为证”、 Palantir……在技术范式以周为单位加速迭代的当下，高频次的知识对齐已不再是简单的“充电”，而是我们构建敏捷型学习组织、缩短从认知到工程落地之间距离的必要生存策略。
第六场内部技术沙龙，我们将聚光灯打向了Harness Engineering（驾驭工程）。其核心是为AI Agent构建一套完整的运行环境、约束规则与反馈闭环，让AI可靠、自主地完成复杂工作。
一、CLI不是盲目怀旧，而是一次“倒退式前进”
拓尔思副总裁曹辉首先讨论了CLI（命令行界面）在AI时代重新受到关注的原因。他指出，在ToB业务场景下，企业无法依赖大厂的云端工具，CLI能够完美适配本地执行的需求，是ToB业务的核心诉求下的必然选择。而当前的CLI并非早期DOS里那种需要记忆大量参数的传统命令行，也不是一种“伪CLI”，其本质是“外壳为LUI，内核为CLI”的最优工程混合体：
- LUI意图层：采用自然语言交互，用户只需表达“做什么”。
- CLI执行层：采用命令行模式，AI Agent通过调用本地命令、操控浏览器、读写文件系统等方式完成具体操作。
这一设计的目标是“剥离中间层，直接触达万物”。曹辉以MCP为例说明：MCP旨在让AI触达各类系统，但落地时受限于厂商是否开放API。而CLI模式，特别是通过控制浏览器，Agent可以模拟人类操作任何B/S架构的业务系统，不依赖厂商配合。
曹辉分享了一个实际操作案例：通过Codex的APP版本，指令一个AI Agent从GitHub下载OpenCLI项目并进行全面分析。该Agent自主完成了拉取代码、解决依赖、构建沙箱环境等任务，在遇到本地缺失工具或需要决策时主动向用户请示，最终生成了一份多维度研究报告。整个过程几乎不需要人工干预。
对企业来说，这意味着什么？ 曹辉的判断很直接：企业无法为每个员工在云端开虚拟机，端侧执行是成本与效率的必然选择。他提出了“云端慢思考，端侧快执行”的架构：云端负责复杂推理和大规模知识检索，端侧负责轻量级执行、本地资源调度和实时响应。
至于Harness Engineering，曹辉认为这是比模型本身更值得关注的趋势。大模型能力正逐渐趋同，未来的技术壁垒正在从模型本身转向Harness Engineering。他通过分析业界顶尖厂商的工程实践，总结了若干设计原则：状态落盘而非驻留内存、生成与评估分离、机械强制优于文本规劝、Auto-Dream机制、多智能体协同等。核心思想只有一个：把不可控的大模型，装进一个可控的工程框架里。

二、Harness到底是什么？一个公式就能说清
北京研发中心的同事引用了LangChain的定义：Agent = Model + Harness。Harness是模型之外的一切代码、配置与执行逻辑，相当于一个运行时系统，将模型的原始能力转化为稳定、可控、可用的工作引擎。他将这一关系类比为CPU与操作系统：模型是CPU，Harness决定了系统的整体体验。
他拆解了Harness的几个核心组件：工具集成（统一校验、权限检查、异常处理）、上下文工程（结构化状态管理，而非简单塞入历史对话）、状态持久化（断点续传、checkpoint）、子代理编排（复杂任务拆解为多个子Agent并行执行）、安全防护（敏感词校验、合规性检查）、可观测性（每一步均有日志可追踪）。每一块都不算新，但把它们组合成一个系统，才是难点。
他特别提到了几个行业案例的细节：Anthropic通过三阶段架构（初始化、执行、评估）与评估智能体，解决了上下文割裂和模型“自我感觉良好”的问题；OpenAI的“动态地图”把长指令文件拆解成约100行的索引式文件，按需加载而非全量塞入上下文，实现了百万行代码的自动化生产；LangChain构建了验证闭环、设置主动退出机制与算力分级，大幅提升模型性能。
另一个设计叫做“推理算力三明治”：在任务规划和最终验收阶段，使用最高等级的推理能力；中间执行阶段，使用低等级推理甚至不进行推理。这样既节省Token，又不影响效果。在他看来，随着模型不断变强，Harness的设计空间并不会缩小，只会移动。AI工程师要做的，是不断找到下一个模型还做不到、但Harness能补齐的点。

三、一个真实的落地案例：让AI自己修Bug
成都研发中心的同事则分享了一个实打实的落地案例。他们团队面对的问题是：数据中台平台里，Sonar检测出了大量代码问题，涵盖不同优先级。同时，测试覆盖率和代码重复率都未达到标准。这些问题让人专门去修，成本高且枯燥，于是他们尝试用AI实现全自动闭环修复。
团队借鉴了Cursor等产品的Master-Worker架构，搭建了一套自动化Bug修复系统：一个Master负责任务分发，多个Worker在隔离环境里独立执行。每个Worker的工作流程是：拉代码 → 分析Sonar issue → 执行修改 → 跑测试 → 提交代码。整个系统与GitLab代码仓库打通，并配有监控面板，可以实时查看任务进度和成功率。
实践中有一个关键发现：在有强验证机制的前提下，小模型也能胜任复杂任务。他们使用的是本地微调的模型，而非商用大模型。对比测试显示：加上Claude Code工程框架后，修复成功率从26.3%提升到40.4%——这部分提升完全来自工程能力。
他还指出一个现实问题，一个任务修下来可能消耗上百万Token，如果全用商用大模型，成本难以承受。因此，Token成本可控是规模化落地的先决条件。同时，任务需要分级处理——简单任务用小模型，复杂任务用大模型或人工介入；减少人机交互、让开发者角色从写代码转向搭建Harness环境，也是提升效率的关键。
截至分享时，这个系统已经处理了300多个issue，修复准确率约80%。他们目前的并发只有3个Agent，后续还会扩大规模。整体来看，这套实践实现了可验证、成本可控、可审计、规模化运行的目标，既提升了Bug修复效率，也为ToB交流提供了有力的叙事——用工程能力弥补模型短板，真正解放人力。

四、把Agent的问题分成三类，然后逐层解决
数字经济研究院同事的分享更工程化。他把Agent落地中遇到的常见问题归纳为失忆、流程失控、作恶/欺骗三类。
对应这三类问题，他提出了三层解法。
第一层：上下文与记忆管理。百万级上下文窗口并不意味着万事大吉，实际使用中，窗口用到40%左右模型就开始“降智”了。所以需要渐进式加载、按需加载、分层记忆。他提到Claude Code的设计：当前任务记忆、任务列表记忆、长期记忆各管各的，而且规定——凡是能推导出来的信息，一律不进记忆。
第二层：流程与编排控制。用规则引擎、Linter强制拦截、DAG编排等方式，把Agent的执行路径“焊死”。比如设置Plan的介入频率、防止死循环、高风险操作强制人工接管。
第三层：验证与护栏。建立验证回路，让Agent能从错误日志里学到东西，而不是一遍遍犯同样的错。同时做安全隔离——从网页抓下来的内容，一律视为“不可信输入”，不能直接执行。
他介绍了数研院的两个产品实践：
- SurgeFlow：浏览器自动化插件，采用Planner（规划）、Navigator（执行）、Validator（验证）三个Agent分工协作，且做好上下文隔离。
- SurgePix：深度搜索Agent，通过DAG编排流程，提升可控性。
他认为，CLI的核心优势不是“命令行”本身，而是可组合性——Agent可以把多个原子命令像搭积木一样组合成新功能，而API很难做到这一点。
目前数研院主要做三件事：打造Agent产品、开发适配Agent的CLI工具、梳理工作流并让Agent替代人工。核心目标是减少人力介入，实现全自动化运行，发挥Agent的带宽优势。

五、从“玩具”到“系统”，Harness的体系化梳理
成都研发中心的同事把Harness的核心机制归纳成四块：前馈约束（执行前注入规范）、感知反馈（执行中自动纠错）、执行器（模型的手和脚）、记忆与状态（用Markdown记录进度）。
他对比了当前两大流派的差异：
- Anthropic是“三智能体”路线：规划者、执行者、评估者各司其职。他们发现，让执行者自己评估自己，就像“又当裁判又当运动员”，效果很差。拆分之后效果明显提升。
- OpenAI是“极致模型”路线：更强调在强模型基础上叠加沙箱、审批、分层指令与上下文压缩等工程约束，通过严格的单向依赖和静态校验，让模型自主发现问题并解决。
两种路线各有优劣，但共同点是：对于复杂的长任务，都必须构建极其严格的验证环境。
他还做了几个重要的区分：
- 编程Harness vs. 业务Harness：编程有编译器、单元测试等“绝对验证方法”，所以Agent 进步飞快。但业务逻辑没有绝对的对错，充满灰度。因此编程Harness的重点是“提速”，业务Harness的重点是“阻止错误、保障稳定”。
- 个人Harness vs. 企业Harness：个人可以100%掌控自己的电脑，追求上限；企业面对的是零信任环境，要防投毒、防注入，核心是“捍卫下限”。难度不在一个量级。
那企业级Harness怎么解？他给出的答案是动态本体——把企业的显规则、隐规则、关联关系都承载在动态本体里，由Agent和人共同持续喂养。一句话总结就是：规则属于动态本体，熔断属于Harness，大模型只负责推理。
关于人机协作模式，他介绍了三种类型：人在环外（AI全自动，适合demo而非长期运行）、人在环内（人工审核，但人的速度会成为瓶颈）、人在环上（系统由Agent驱动，人从根源优化Harness体系）。正确的模式显然是第三种：人关注Why，AI处理How。

六、拓尔思技能库建设中的一线经验
成都研发中心的另一位同事，带来了拓尔思技能库（Skill Hub）建设中的一线经验。团队从实际问题出发，逐步总结出六条核心原则：
第一，避免AI自我评估。AI对其自身输出容易产生盲区，必须由另一个独立的AI或Agent进行评估，并将错误原因反馈给执行者。
第二，限制重试次数。不应允许AI无限重试，通常尝试两次仍失败即应终止，防止陷入死循环。
第三，使用Checklist管理状态。长任务执行过程中AI容易出现“遗忘”现象，需要引入类似人类打勾记录的方式，让后续Agent能够明确当前进度。
第四，不默认AI已知任何未明确告知的信息。即使某些知识可能存在于模型的预训练数据中，也不能依赖这种假设。所有关键知识必须单独整理成文档，作为“系统事实的唯一来源”明确提供给AI。
第五，确保每一步可观测。AI的思考过程、读取内容、输出结果、耗时等信息均需完整记录。否则一旦出现问题，无法快速定位是代码缺陷还是模型理解偏差。
第六，以上条件满足后，AI才能一次输出可用的Skill。

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