作者 / 来源：中智凯灵 / AiDD

——从 AiDD 北京站四场实践，看生产级 Agent 的可靠执行环境

▼

把一个百万行级代码库交给 Agent 重构，企业凭什么敢让它继续跑？

不是因为模型“看起来很聪明”，也不是因为它已经能读仓库、改文件、跑命令。真正让人放心的，是另一组更具体的问题：它读到的是不是当前有效的事实？能修改哪些范围？每一步由什么验证？失败之后留下了什么证据？下一次执行能不能从这次失败中继续？

在 2026 AiDD 北京站，中国移动云公司 AI 技术研究员张燚钧在《移动云基于 Harness 的 AI 原生开发实践》中给出了一个直接判断：模型负责推理，Harness 负责把推理接入真实世界。

这里的 Harness，很难用“脚手架”三个字简单概括。它不是一套固定提示词，也不是给 Agent 套一个外壳，而是围绕一次真实任务，把上下文、工具、权限、运行环境、验证机制、状态管理和反馈回路组织起来，让 Agent 能在明确边界内持续工作。

如果说模型决定 Agent 能想到什么，那么 Harness 决定它能看到什么、能做什么、如何证明自己做对了，以及失败之后怎样继续。

图 1：张燚钧《移动云基于 Harness 的 AI 原生开发实践》：Harness 落地的五个关键点（PPT 第 9 页）

Agent 会写代码，不等于企业敢让它交付

今天的 Coding Agent 已经能完成相当复杂的单点任务：理解需求、检索代码、生成计划、修改文件、运行测试，甚至根据报错继续修复。问题在于，真实交付从来不是一次“生成成功”。

在个人试验里，开发者可以盯着 Agent 的每一步，发现方向不对就立即叫停；进入企业环境后，任务会跨越更大的代码库、更长的执行时间和更多外部系统。上下文可能失效，工具调用可能越界，批量修改可能放大局部错误，测试通过也未必等于业务验收完成。

因此，生产级 Agent 的关键差异，不只是“自主性更强”，而是自主性被放进了一套可验证的工程环境。

张燚钧把 Harness 的落地点归纳为五个方面：仓库成为可发现、可版本化的事实源；目标被改写为明确的完成定义、测试和性能基线；Agent 可以自主选择实现路径，但编辑入口、工具权限、架构不变量和高危操作受到限制；执行之后立即进入测试、评审、回扫或压测；最后，Spec、Plan、ADR、Skill、测试、报告和决策记录重新进入仓库，成为下一次工作的上下文。

这五点共同回答的，不是“怎样让 Agent 多做一点”，而是“怎样让每一次自动执行都留下可判断、可追溯、可复用的结果”。

Harness 不是一条标准流水线，而是对不确定性的设计

企业很容易把 Harness 理解成一条更智能的 CI/CD 流水线。但在张燚钧分享的五类案例里，真正需要被控制的不确定性并不相同。

DBaaS 百万级代码重构面对的是项目过大、上下文容易丢失和批量变更风险。对应的 Harness 重点，是仓库事实源、分段执行和多级质量门禁。

vLLM 推理引擎调参面对的是参数组合爆炸、实验耗时和资源残留。它需要的不是更多对话，而是固定编排器、单一编辑入口、自动实验循环和明确的 SLO 指标。

OA Banner CLI 改造面对的则是另一类问题：业务能力被封在页面里，Agent 即使理解了用户意图，也没有稳定、结构化的执行接口。因此，关键动作变成把 GUI 能力转成 CLI，补齐接口文档、鉴权和真实环境验证。

MySQL 数据库迁移的难点，是历史系统里散落着大量隐性兼容规则。单纯让 Agent 改写 SQL 远远不够，还要建立迁移、测试、适配三类闭环，把接口清单、兼容条件和验收用例变成可执行规则。

数据库内核优化的方案空间更大，错误代价也更高。此时人的责任不是逐步替 Agent 操作，而是定义方向、不变量和最终合入标准；Agent 扩大搜索，Harness 用性能、正确性和质量门禁筛选结果。

图 2：张燚钧《移动云基于 Harness 的 AI 原生开发实践》：不同任务需要针对主要不确定性设计 Harness（PPT 第 10 页）

这些案例说明，Harness 的本质不是消灭不确定性。复杂任务不可能被预先写成一条毫无分支的流水线。它真正做的，是把不确定性关进一个受控过程：允许 Agent 探索，但要求边界明确；允许方案失败，但失败必须可定位；允许多轮尝试，但每一轮都要产生证据。

同一个模型，放进不同 Harness，能完成的工作和风险上限可能完全不同。真正可复用的也不是某一句提示词，而是“这一类任务应该怎样被执行、验证和接管”的工程设计。

图 3：张燚钧《移动云基于 Harness 的 AI 原生开发实践》：五类任务如何把不同不确定性关进可验证过程（PPT 第 27 页）

从一次 AgentRun 到可验收任务，中间还缺一份“运行时契约”

如果 Harness 只存在于开发者个人电脑里，它仍然很难成为企业能力。生产任务需要跨会话、跨角色、跨系统持续推进，还要让人的授权和判断随时进入。

商汤科技高级工程师周清峰在《从 Copilot 到 Agent：小浣熊客户端的工程化实践与交付闭环》中，把 Agent 的交付环境拆成控制面、运行面和资源面。

客户端承担对话、计划、工作区、预览和权限确认；Agent Runtime 负责目标循环、上下文装配、工具选择、Skill 激活、子任务和质量约束；资源面提供文件、数据源、知识库、Memory、MCP、沙箱与远程服务。它们之间传递的不是一段最终文本，而是计划、权限、工具调用、产物和状态事件。

这个拆分的意义是：界面不再假装自己知道模型“想到了哪一步”，而是消费 Runtime 真实产生的结构化事件；Agent 也不再只靠一段不断膨胀的对话维持任务，而是在持续存在的运行环境中推进。

图 4：周清峰《从 Copilot 到 Agent：小浣熊客户端的工程化实践与交付闭环》：控制面、运行面、资源面与运行时契约（PPT 第 15 页）

周清峰还把 Plan Mode 定义为用户与运行时之间的“任务契约”。一份可执行的 Plan 至少要说清目标与业务约束、任务顺序与依赖、输入输出边界、缺失信息与权限风险，以及用什么结果判断完成。

这与让模型展示思维过程不是一回事。企业需要的不是旁观 Agent 的所有内部推理，而是在执行前确认范围，在高风险节点保留授权，在完成时拿到可验收证据。

当目标、资源、风险和验收被写进同一份契约，Agent 的自主执行才不再是一个黑箱动作，而成为可以暂停、补充、恢复和追责的工程过程。

图 5：周清峰《从 Copilot 到 Agent：小浣熊客户端的工程化实践与交付闭环》：Plan 把目标、资源、风险和验收写成可确认的任务契约（PPT 第 20 页）

Harness 不能停在 IDE，它必须进入真实项目现场

一个运行良好的 Coding Agent，只解决了研发链路中的一个节点。需求还在 Jira 和文档里，测试环境由另一套平台管理，发布要经过审批，异常由监控系统发现，项目状态则散落在群聊和会议中。只要这些节点仍靠人搬运上下文，Agent 在 IDE 里再快，项目也不会等比例变快。

去哪儿旅行基础架构基础平台负责人、技术总监李晓悦在《AI 驱动的项目全周期流程重塑与落地实践》中展示了“天弦”平台的一种做法：入口接入飞书、Jira 和 Dashboard，调度中心负责任务分发、策略控制与生命周期管理；隔离运行实例组合 Agent、代码仓库、编译环境和企业 Skills，完成从理解需求、修改代码到编译、测试和输出结果的连续执行。

这可以看作 Harness 从个人工具走向企业基础设施的一步：Agent 不再临时借用开发者机器上的环境，而是在可隔离、可调度、可观察的实例中工作；组织已有的规范检查、部署、状态检测和日志分析，也被封装成它可以调用的能力。

图 6：李晓悦《AI 驱动的项目全周期流程重塑与落地实践》：隔离运行实例整合 Agent、编译环境与企业 Skills（PPT 第 18 页）

但端到端交付并不意味着让一个 Agent 包办所有事情。去哪儿的项目小助手以项目群为维度，把需求规划、研发质量、测试发布和运维反馈串在一起；每到关键节点，再根据风险选择半自动、全自动或动态编排。

其中真正重要的不是“流程画得更长”，而是每个节点都有明确输入、输出、负责人和验收方式。横向的项目流程负责推进状态，纵向的专业能力负责保证每个节点的深度。二者缺一，所谓端到端都容易退化成一次更长的自动化演示。

图 7：李晓悦《AI 驱动的项目全周期流程重塑与落地实践》：项目小助手串联需求、研发、测试发布与运维反馈（PPT 第 45 页）

人的介入也不应该按“AI 会不会做”划分，而要按失败代价划分。单测生成、回归选 Case、缺陷识别等低风险且结果可验证的任务，可以让 AI 自主完成；代码评审关键意见、发布审批等风险更高的动作，需要人审核；业务优先级和灰度策略直接影响经营结果，则必须由人作最终决策。

这也是 Harness 的一个重要边界：它不是为了把人从流程中清空，而是让人的注意力从重复执行转向目标、边界、例外和责任。

图 8：李晓悦《AI 驱动的项目全周期流程重塑与落地实践》：人机边界应随任务风险与失败代价逐级收紧（PPT 第 55 页）

没有反馈闭环，Harness 仍然只是静态外壳

一套 Harness 即使在今天运行良好，也不意味着下一个版本仍然可靠。模型会更换，Prompt、Skill、Tool 和知识库会持续变化，业务规则与权限也会调整。任何一个环节变化，都可能让过去正确的执行路径发生退化。

阿里云高级产品专家夏明在《Agent 自进化：企业级智能体全生命周期进化飞轮实践》中，将治理对象从 LLMOps 的单次调用，推进到 AgentOps 的完整任务：不只看 Prompt 到 Response，而是看 Goal 到 Task Completion；不只看输出准确率，还要观察规划、工具、记忆和状态迁移组成的完整 Trajectory；不只评估模型指标，还要判断任务是否完成、流程是否正确、业务价值是否闭环。

图 9：夏明《Agent 自进化：企业级智能体全生命周期进化飞轮实践》：治理对象从单次回答升级为完整任务与推理轨迹（PPT 第 5 页）

当运行轨迹被采集下来，它才可能进入评估、归因和改进。夏明将这些数据进一步沉淀为四类资产：基准集用于模型切换和大版本升级时锁定质量底线；测试集用于复现低分样本和验证修复；回归集用于 Prompt、Skill、Tool 或知识库变更后的防退化；后训练集则积累高质量轨迹、专家标注和黄金样本。

这一步把“Agent 用得越多”与“Agent 变得更好”区分开来。没有结构化轨迹、稳定评测和版本对比，更多调用只会产生更多日志；只有把 Bad Case 变成题库，把修改变成候选版本，把候选版本放进回归与小流量验证，经验才会真正回到 Harness。

图 10：夏明《Agent 自进化：企业级智能体全生命周期进化飞轮实践》：基准集、测试集、回归集和后训练集构成可复用数据资产（PPT 第 20 页）

企业真正要建设的，是“让 Agent 工作的系统”

回看这四场分享，Harness 并不是某一款产品的专属功能，也不是一个需要一次性建成的庞大平台。它更像一组围绕真实任务逐步长出来的工程机制。

起点可以很小：选择一个边界清晰、结果可验证的任务，把需求、规则和完成定义写进可版本化的事实源；只给 Agent 最小必要工具与权限；先打通一次“执行—验证—修复—再验证”；然后把高频动作沉淀为 Skill，把确定性规则沉淀为脚本和门禁，把失败样本沉淀为回归资产。

当任务出现更多角色、分支和并行，再引入多 Agent 与更复杂的编排；当任务进入生产，再补齐轨迹观测、风险审计、实验回测和人工接管。Harness 不是先画一张满配架构图，再寻找场景，而是从一条真实闭环开始，让每次运行都为下一次运行留下东西。

模型会继续升级，Agent 的自主工作时间也会继续变长。但企业最终能不能把这些能力变成稳定交付，不取决于模型在一次演示里完成了多少，而取决于组织有没有把事实、边界、工具、验证、反馈和责任写进它工作的环境。

模型决定上限，Harness 决定这份能力能不能进入生产。

 主要参考演讲

9 月 19 日，AiDD 2026 成都站还将继续讨论 Agentic 开发、Agent 评测与质量保障、Testing Agent Harness、研发效能等方向。日程仍在动态更新，最终安排以大会官网为准。