> **来源：[研报客](https://pc.yanbaoke.cn)** # 驾驭工程（Harness Engineering）研究报告总结 ## 核心内容 驾驭工程是AI系统开发中的一项关键工程实践，被定义为操作系统层，与提示词工程（语言层）、智能体工程（工作流层）共同构成AI工程的三层架构。它不是对提示词工程的简单延伸，而是将模型执行环境制度化，实现高自治、长时程、可治理的AI系统。 ## 主要观点 - **提示词工程**：关注“怎么说清楚”，解决短时、单步任务的指令表达问题。 - **上下文工程**：解决状态供给问题，是AI系统运行的“隐形内核”，但上下文有限且容易“腐烂”。 - **智能体工程**：关注“怎么让模型动起来”，通过工具和流程设计实现复杂任务的执行。 - **驾驭工程**：是系统级环境设计，关注“怎么让系统持续稳定运行”，涵盖六个关键负重部件，包括完成契约、系统记录、Agent感官、状态恢复、评测回路、边界控制与熵管理。 ## 关键信息 ### 四层链条 - **语言层**：提示词工程，解决“怎么说清楚”。 - **状态层**：上下文工程，解决“喂给模型什么”。 - **工作流层**：智能体工程，解决“怎么让模型动起来”。 - **制度层**：驾驭工程，解决“怎么让系统持续稳定运行”。 ### 驾驭工程的六个负重部件 1. **机器可验证的完成契约**：定义任务完成的标准，包括输入边界、输出要求、验证方法和停止条件。 2. **Durable Knowledge 的 System of Record**：将知识转化为可版本控制的系统记录，避免依赖长提示词。 3. **Agent的感官和手脚**：提供真实的数据输入和输出，如UI、日志、指标、traces等。 4. **解决长时程失忆**：通过progress file、feature list、git与init script等技术手段实现状态可恢复、可交接和可继续。 5. **外置评测回路**：确保系统在没有人工干预的情况下也能稳定运行，包括回归测试、Grader、监控大屏等。 6. **边界、沙箱与熵控制**：通过身份与授权、最小权限、统一管理等机制控制系统行为，确保安全与可治理。 ### 人的角色转变 - **从表达者到设计者**：人的工作抽象层上移，从设计输入指令转向定义系统行为与评估标准。 - **组织能力的重要性**：驾驭工程不仅依赖模型能力，更需要系统化的组织能力，包括产品、工程、治理和运营的协同。 ## 中国落地窗口 ### 政策与环境 - **政策支持**：2025年政府工作报告推动“人工智能+”进入具体任务书，政策语义从技术转向应用。 - **网络与数据基础**：中国拥有11.08亿网民，互联网普及率78.6%，数字经济核心产业增加值达140891亿元，具备良好的数字化基础。 - **企业优势**：中国企业在场景丰富性、工程人才储备和流程密集度方面具有独特优势，适合先从高频、可量化、低风险的场景切入。 ### 优先落地场景 1. **客户支持与工单分流**：智能客服、工单分类、知识检索等，适合Agent预处理和系统执行。 2. **销售运营与线索跟进**：实现半自动驾驶，提升转化效率。 3. **制造现场**：适用于研发设计、视觉质检、参数优化等，具备明确的指标和验证机制。 4. **财务与合规**：适合做辅助性工作，避免全自动裁决带来的风险。 5. **企业知识运营**：作为System of Record的练兵场，实现知识的版本控制和自动化应用。 6. **流程自动化（RPA+AI）**：适用于重复性、跨系统任务，提升效率与准确性。 ### 实施路线与成熟度模型 - **五级成熟度模型**： 1. **一级：演示型使用**：单点辅助，流程点缀。 2. **二级：单点辅助**：特定任务，流程优化。 3. **三级：Agent感官**：提供真实输入输出，增强代理能力。 4. **四级：状态恢复**：通过工具和机制实现状态可恢复、可继承、可审计。 5. **五级：系统级稳定**：外置评测、监控、治理机制完善。 - **30/60/90天推进法**： - **30天**：定义完成契约，明确任务目标。 - **60天**：将知识搬入版本化系统，避免依赖长提示词。 - **90天**：建立Agent感官与状态恢复机制，实现系统持续运行。 ### 指标体系 - **系统级经营指标**：完成率、异常率、人工接管率、恢复时长、单位任务成本。 - **高频场景指标**：吞吐量、夜间无人值守比例。 ## 反模式与边界 - **反模式一**：把大长提示词当作Harness，忽略系统记录和状态恢复。 - **反模式二**：混淆Workflow、Agent和Harness，导致设计、评测与投资预期错位。 - **反模式三**：工具越多越好，忽视选择噪声和上下文负担。 - **反模式四**：过早追求完全自治，忽视验证与人工干预的必要性。 - **反模式五**：让主Agent同时承担执行与评测，缺乏外部监督。 - **反模式六**：忽视状态恢复设计，导致系统在长任务中失忆。 - **反模式七**：过早追求复杂性，增加维护与错误面。 ## 一句话结论 驾驭工程不是把提示词再写长一点，而是把模型周围整个制度化执行环境设计出来。