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

——第10 届AiDD 北京站大会观察（1）：企业AI 正从单点工具走向可靠交付系统

▼

当一个Agent 已经能够读代码、改文件、调用工具、执行命令，甚至连续完成一段任务时，企业AI 落地是不是就快成功了？

恰恰相反。模型越能做事，过去被模型能力遮住的工程问题就越快浮出水面：业务意图有没有被准确理解，任务能不能跨阶段持续推进，结果由谁验证，高风险动作如何授权，失败经验怎样回流，个人形成的高效方法能不能变成组织能力。

8月21-22 日，第10 届AI+研发数字峰会（AiDD 2026 北京站）圆满落幕。从Keynote 到AI+研发效能、智能测试、数据与知识检索、Agentic Engineering、组织与人才等不同方向，多场分享共同呈现出一个清晰变化：行业关注点正在从“模型能不能生成”，转向“企业能不能把AI 组织成稳定的生产系统”。

这不是一次简单的工具升级。AI Coding、Agent、知识库、Harness、评测和FDE 看似分属不同话题，实际上都在回答同一个问题：当AI 开始参与真实工作，企业怎样让它交付可验收结果，并在一次次运行中变得更可靠？

北京站给出的答案，可以概括为五个转向。

过去讨论AI 编程，最容易观察的指标是生成速度：一段代码过去要写几个小时，现在可能只要几分钟；一个原型过去要几天，现在一个人就能快速搭出来。但企业软件的真实交付从来不只有编码。

字节跳动TRAE 研发团队技术专家张皓洋 在《从Coding 到Engineering：AI 如何参与TRAE 的真实研发流程》中，先解释了AI Coding 为什么很强，也解释了它为什么容易停在Demo。模型加上Harness，已经能够在一次会话里读仓库、改文件、跑命令、看测试和生成Diff；但稳定交付仍然依赖一系列前置条件：需求被正确理解，方案经过设计，任务得到拆解，改动能够审查，验证留下证据。

这五个缺口说明，模型解决的是“当前节点怎样做得更快”，Engineering 要解决的则是“整件事怎样持续向前”。如果需求仍然模糊、方案约束仍靠口头传递、验证仍由执行者自己宣布完成，生成再快，也可能只是更快地产生返工。

图 1：张皓洋《从 Coding 到 Engineering：AI 如何参与 TRAE 的真实研发流程》：AI Coding 为什么容易停在 Demo（PPT 第 5 页）

张皓洋用个人提效与组织提效之间的差距进一步说明了这一点。编码速度可以提升很多倍，组织吞吐却不会等比例提升。需求澄清、方案评审、上下文交接、测试验证和发布协同，只要还有一个环节没有被重构，局部速度就会被等待、沟通和返工重新吸收。

因此，从Coding 到Engineering，不是给代码生成再增加几个功能，而是把需求、设计、实现、验证、发布和反馈重新组织成一条可持续推进的工作链。AI 的价值也随之发生变化：它不再只替人完成某个动作，而是开始参与一整套交付关系。

图 2：张皓洋《从 Coding 到 Engineering：AI 如何参与 TRAE 的真实研发流程》：编码提速不等于组织吞吐同步提升（PPT 第 9 页）

当AI 从一个研发节点进入更长的业务流程，新的判断标准也会出现。过去评估一个助手，常问它回答得准不准、生成得像不像；评估一个进入生产的Agent，则必须追问它能否在规则和权限范围内，稳定完成任务并交付结果。

NoDesk AI CTO 王仿 在《从大模型到 AI 执行系统：构建企业级可控 Agent 体系》中，把企业 AI 的进化分成 Chat、Copilot、Workflow、Agent 和 Execution System 五个阶段。前几个阶段主要在协助人做事，Execution System 则开始直接面向业务结果。

这一区别看似只是名称变化，背后却意味着责任边界完全不同。一个回答错误的聊天助手，用户可以重新提问；一个能够调用系统、修改状态、触发流程的Agent，一旦理解错目标或越过权限，影响的就可能是订单、审批、发布、合规和客户体验。

图3：王仿《从大模型到AI 执行系统：构建企业级可控Agent 体系》：企业AI 从“副驾驶”走向“交付系统”（PPT 第5 页）

因此，生产级Agent 不能只是“模型外面套一个工作流”。王仿提出，Agent 长期进入真实业务，需要同时满足准确、可控、安全合规、可观测和人机协同等要求。模型、上下文、知识、Skill、工具、权限、日志和任务状态，要进入同一套运行体系；长链路还需要检查点、人工确认、异常回退和审计记录。

这也是为什么企业AI 的瓶颈正在从“有没有模型”转移到“有没有执行系统”。模型决定Agent 能想到什么，执行系统决定它能做什么、做到哪一步必须停下来、结果怎样被验证、出错后能不能恢复。真正的生产能力，不是让AI 获得无限自主权，而是让自主能力始终运行在可治理的边界内。

图4：王仿《从大模型到AI 执行系统：构建企业级可控Agent 体系》：生产级Agent 运行底座需要同时满足五类要求（PPT 第8 页）

研发速度提升以后，最先承受压力的往往是测试与质量体系。代码和变更产生得更快，如果验证仍然主要依靠人工编写脚本、逐条执行和末端回归，效率红利很快就会在质量环节形成新的拥堵。

Testin云测CEO 徐琨 在《研发已提速10 倍，测试怎么办？——从错判到重构：AI 测试这两年我看到的三件事》中，没有把答案归结为“再做一个更大的测试模型”。他的判断是，大模型擅长语义理解、场景分析和脚本生成，但确定性执行、跨平台适配、精准断言和大规模回归，需要不同能力共同完成。

因此，他给出的方案是三位一体：大模型负责生成与推理，人负责关键节点的验收与校准，稳定执行引擎负责跨平台并发执行和结果回溯。这个分工的价值，不是限制AI，而是让不同能力回到最合适的位置。

图5：徐琨《研发已提速10 倍，测试怎么办？——从错判到重构：AI 测试这两年我看到的三件事》：大模型、人和执行引擎组成测试协同体系（PPT 第15 页）

在具体执行上，生成脚本和运行脚本也被进一步分开。大模型可以把自然语言用例转成脚本，经过人工确认后固化；大规模回归再交给更确定、成本更可控的执行体系。执行失败时，AI 先诊断和提出修复动作，修复结果经过验证后才进入正式资产。

这揭示了AI 原生质量体系的一条基本原则：不能让同一个Agent 同时负责实现、判定自己是否正确，并宣布任务完成。需求、实现、验证和放行之间需要相互制衡；测试报告、日志、截图、Diff、评测结果和人工决策，都应该成为可回看的证据。

质量不再只是流程最后的一道门，而要进入任务定义、执行过程、异常处理和反馈回流。AI 越能自主行动，企业越需要把“为什么相信它完成了”设计进系统。

图6：徐琨《研发已提速10 倍，测试怎么办？——从错判到重构：AI 测试这两年我看到的三件事》：固化脚本由确定性体系执行，兼顾效率、稳定性与跨端适配（PPT 第23 页）

Agent要持续完成复杂任务，靠的也不只是更长的上下文窗口。代码、文档、规则、历史决策、工具结果和失败轨迹不断进入系统，如果只是把更多材料塞给模型，成本、噪声和冲突都会一起增长。

北京奥星贝斯OceanBase 技术专家汤庆 在《从静态检索到动态自进化：ContextSeek 如何让Agent 持续提升》中提出了一个很有代表性的判断：“能检索”不等于“会积累”。一个Agent 即使接上知识库，换一种问法仍可能答非所问；一个Coding Agent 即使花两个小时定位出兼容性问题，窗口关闭后，经验也可能随之消失。下一次遇到类似问题，它还会重新读代码、重新踩坑、重新支付推理成本。

图7：汤庆《从静态检索到动态自进化：ContextSeek 如何让Agent 持续提升》：“能检索”不等于真正“会积累”（PPT 第8 页）

解决这个问题，需要把知识库、记忆、执行轨迹和Skills 放进统一的上下文语义层。原始材料先被抽取和验证，多个片段再收敛为稳定知识；被反复验证的成功路径，进一步沉淀为可执行Skill。每一步演进都保留来源和关系，错误、冲突与过时内容也能够被识别和处理。

这样一来，Agent 得到的不再是一堆静态文档，而是一组带来源、版本、权限、置信度和使用记录的上下文资产。一次任务留下的不只是最终答案，还包括过程证据、失败原因、人的判断和可复用经验。

这也是企业AI 能力产生复利的前提：让下一次任务不是重新开始，而是站在上一次被验证的结果上继续。知识真正的价值，不在于保存了多少，而在于能否进入执行、接受验证并持续演进。

图 8：汤庆《从静态检索到动态自进化：ContextSeek 如何让 Agent 持续提升》：上下文从 Raw、extracted、knowledge 逐步演进为 Skill（PPT 第 16 页）

当AI Coding、执行系统、质量证据和上下文资产逐步连起来，最后一个问题就不再是技术问题，而是组织问题：这些能力究竟属于少数“超级个体”，还是能够被团队稳定复用？

去哪儿旅行基础架构负责人、技术总监李佳奇 在《从基础架构到超级团队：AI 时代的技术组织进化实践》中，展示了AI 从研发工具走向组织平台的过程。AI 研发平台“天弦”覆盖从技术需求到业务需求、本地到云端、研发全流程自动化和研发团队完整覆盖；同时，AI 运营与AI 数据分析也形成各自平台，进入不同业务线和经营场景。

这类实践的关键，不是组织采购了多少工具，而是把共用基础设施、任务流程、上下文、验证方式和业务经验沉淀到平台里。只有能力可以被发现、被调用、被度量、被维护，个体效率才可能变成组织吞吐。

图9：李佳奇《从基础架构到超级团队：AI 时代的技术组织进化实践》：AI 研发平台“天弦”推动研发能力走向全流程覆盖（PPT 第24 页）

组织能力的形成，还需要新的角色把业务现场和工程体系连接起来。AI 大模型落地实战专家、企业智能化转型首席顾问李明宇在《FDE 落地三年：从行业实践探索到可复用方法论》中，把Agent 拆成Model 与Harness 两部分。模型提供推理和生成，Harness 则组织上下文、工具、规则、权限、验证和反馈，让概率性能力进入可控、可治理、可观测、可持续的工程闭环。

这也解释了FDE 的价值。它不是换一个岗位名称，也不是把工程师简单派到现场，而是有人能够把业务意图翻译成AI 可执行任务，把真实样本、工程约束和评估证据组织起来，再推动能力进入生产和持续运营。

当平台、角色和资产同时变化，AI 才不再依赖少数人的个人技巧。组织可以把一次项目中的Rules、Skills、评估集、任务模板和失败经验留下来，使下一次落地不必从零开始。

图 10：李明宇《FDE 落地三年：从行业实践探索到可复用方法论》：Harness Engineering 将上下文、工具、规则、权限、验证和反馈组织成工程闭环（PPT 第 19 页）

从北京站多场分享中，可以看到企业AI 落地的主线正在发生变化。

- 从Coding 到Engineering，意味着关注点从代码生成转向完整交付；

- 从助手到执行系统，意味着Agent 开始对业务结果负责；

- 从末端测试到全过程证据，意味着质量进入每一次任务运行；

- 从静态知识库到可进化上下文，意味着经验能够持续积累；

- 从个人提效到组织能力，意味着平台、角色和资产需要共同升级。

这些变化最终指向同一个判断：企业AI 的竞争，正在从“谁先用上更强的模型”，转向“谁先建成更可靠的交付系统”。

模型能力会持续进步，工具也会不断更新，但需求怎样被表达、上下文怎样流动、任务怎样推进、结果怎样验证、权限怎样治理、经验怎样回流，都不会因为模型升级而自动解决。它们需要被设计成工程系统，也需要在真实业务中反复运行、校准和沉淀。

Agent会做事，只是起点。

企业真正要建立的，是一套让AI 能够持续把事情做对、把结果交出来，并且一次比一次更可靠的运行方式。