2026智能研发时代企业驾驭工程落地实践报告-中国通信标准化协会

1当前，软件产业已形成成熟、精益、可度量的现代化研发体系。与此同时，AIAgent（智能体）技术快速普及，具备自主规划、上下文推理、工具调用与闭环执行能力的研发智能体，正深度渗透IT研发全链路，推动传统自动化模式向人机协同的新型研发形态演进。然而，研发智能体从单点试点走向企业级规模化部署的过程中，工程落地与治理难题愈发突出。AIAgent行为动态化、决策概率化、输出不确定性强的特征，使传统研发范式、质量管控与安全治理体系无法有效适配。行业普遍面临意图精准理解难、知识供给质量不足、产物缺少标准化验证、工具调用存在安全风险、个体提效无法转化为组织能力等核心痛点。驾驭工程是一套为智能体构建完整运行环境、约束规则与反馈闭环的系统工程方法，使AI在人类设定边界内自主、可靠、可持续完成复杂任务，并非旨在替代DevOps、平台工程等现有体系，而是在此基础上叠加面向智能体的专属管控能力，以实现任务可定义、过程可审计、结果可验证、成本可度量、能力可沉淀。本报告将系统梳理研发范式演进脉络，深度拆解AI研发智能体规模化应用的核心挑战，完整阐释驾驭工程的定义、五层架构与核心能力，提炼关键能力模块与标准化实施路径，结合标杆企业实践案例总结可复用的落地经验，前瞻研判技术演进与产业趋势，为企业规模化落地智能研发提供针对性发展建议与重要参考。本报告由中国通信标准化协会TC628标准推进委员会牵头编写，主要参编单位包括中国信息通信研究院、北京趣拿软件科技有限公司、中移九天人工智能科技（北京）有限公司、中国银河证券股份有限公司、申万宏源证券有限公司、上海金融期货信息技术有限公司。2一、背景与范式演进概述 5（一）研发范式迭代演进脉络与范式特征 5（二）AIAgent介入驱动研发范式新型变革 7（三）驾驭工程内涵界定与演进路径 二、研发侧驾驭工程落地主要痛点 （一）意图鸿沟：自然语言到工程任务的转化难题 （二）上下文壁垒：企业知识资产治理与供给短板 （三）交付断层：智能体生成产物验证与证据缺失 （四）安全风险：工具调用与自主执行的治理隐患 （五）效能瓶颈：Token成本管控与价值转化低效 （六）组织断层：个体提效与组织级效能的适配差距 三、驾驭工程核心能力体系 （一）研发视角下的驾驭工程定义 （二）驾驭工程与其他主流工程体系关联与对比 （三）驾驭工程五层能力架构 四、企业驾驭工程落地原则与实施路径 （一）企业驾驭工程落地实施原则 （二）六步标准化落地实施路径 （三）研发领域实践场景地图 五、企业实践典型案例 （一）北京趣拿软件科技有限公司：去哪儿旅行AICoding全流程Harness实践 3（二）中国银河证券股份有限公司：银河证券面向研发全流程的UserHarnessEngineering实践 43（三）申万宏源证券有限公司：基于AI智能体的业务领域知识驱动测试用例生成实践 48（四）上海金融期货信息技术有限公司：从业务意图到可信交付-基于规格驱动的组织级智能研发范式建设实践 （五）中移九天人工智能科技（北京）有限公司：中国移动灵畿平台基于SDD开发的Harness实践 六、未来展望 63（一）人机协同下的组织转型 （二）Agent协作治理平台搭建 654图1研发范式迭代演进脉络 7图2驾驭工程运行五层架构 22图3人与AI划定权责边界的两种模式 29图4驾驭工程落地六步实施路径 31图5驾驭工程实践场景地图 34图6去哪儿旅行AICodingHarness实践整体流程图 37图7去哪儿旅行AICodingHarness设计方案 38图8去哪儿旅行天弦平台整体架构图 40图9银河证券UserHarnessEngineering实践架构图 45图10申万宏源业务领域知识驱动用例生成流程图 50图11中金所SDD双环交付协同图 52图12中国移动灵畿平台Harness整体架构图 57图13代码安全三阶段工作流程图 60表1大模型工程范式演进阶段 表2各工程体系对比 表3安全治理层能力维度 表4试点场景选择评估维度 表5评估闭环机制错误类别 表6四类AI核心对象职责划分 表7角色核心职责 5（一）研发范式迭代演进脉络与范式特征研发范式的发展史，本质是一部持续应对系统规模与复杂性挑战、迭代升级工程模式的变革史。自概念诞生以来，行业已先后完成多轮系统性范式跃迁，每一次变革均精准回应了特定发展阶段的核心矛盾，推动软件产业实现量级式增长。1.从瀑布到敏捷：从计划驱动到快速反馈早期的研发范式深受瀑布模型影响，它将软件开发生命周期严格划分为需求、设计、编码、测试和维护等线性和顺序的阶段。该模型强调详尽的预先规划、完备的文档体系以及阶段间的正式评审，适用于需求高度稳定、系统边界清晰的确定性项目。其核心逻辑在于通过流程的确定性来保证软件质量的可预测性。然而，随着商业环境的动态化与需求不确定性的加剧，瀑布模型的弊端日益凸显：冗长的交付周期导致市场反馈严重滞后，前期固化设计难以响应变化，质量风险集中于后期测试阶段，整体交付价值流效率低下。因此，敏捷开发应运而生，它并非否定流程与规划，而是将关注点从僵化的计划遵从转向流动的价值交付。敏捷范式的核心转变在于其管理哲学的重构，即从管理过程与文档转向管理工作软件与快速反馈；从依赖阶段性交接与审批转向依赖跨职能团队的紧密协作与持续改进。其目标是建立一个高适应性、能够持续交付业务价值的精益交付系统，而非仅仅提升单个开发环节的效率。从组织视角看，敏捷转型的深层价值在于重构了价值流动的管道：它打破了“需求方-开发方-测试方”的职能竖井，将产品、开发和测试整合为面向业务目标的自组织团队。62.从敏捷到DevOps：从团队协作到端到端价值流敏捷实践有效地优化了产品、开发与测试团队间的协作效率，但其影响范围主要局限在开发领域。软件从代码提交到最终为用户创造价值，还需经过构建、集成、部署、运维、监控及用户反馈等复杂环节，这些环节之间的协作断层与手动操作构成了新的瓶颈。DevOps（研发运营一体化）的出现，标志着研发范式的第二次关键跃迁：将工程化实践从开发环节拓展至端到端的价值交付流。DevOps的核心主张是通过文化、实践与工具的融合，打破开发（Dev）与运维（Ops）之间的传统壁垒，建立围绕软件交付全过程的协作体系。它通过持续集成（CI）、持续交付/部署（CD）、基础设施即代码（IaC）、自动化测试与监控等实践，将交付过程本身工程化、自动化与可度量化。其本质是构建一个从代码变更到用户价值的高可靠性、短周期、自动化的交付管道，从而实现业务敏捷性的根本提升。因此，DevOps不仅是工具链的自动化，更是一种系统性的工程思维，旨在将软件交付转化为一个可预测、可持续改进的工业化流程。DevOps的成功实施不仅依赖工具链自动化，更是一场深刻的组织与文化变革。它要求企业建立以产品为导向的跨职能团队，赋予团队端到端产品全生命周期所有权，并通过效能度量与实验文化驱动持续优化。这种从项目制交付到产品制运营、从局部环节优化到全价值流全局优化的转变，为传统研发范式引入了更高阶、价值流驱动的系统性工程思维。3.从DevOps到平台工程：从实践赋能到能力产品化当DevOps实践在组织内规模化推广时，一个普遍困境随之出现：各个团队自行建设和维护工具链，导致能力重复建设、技术栈碎片化、安全与合规标准难以统一，总体拥有成本居高不下。平台工程正是应对这一规模化挑战的进化方向，其定义为一组用于设计、构建和运营支持软件价值交付和生命周期管理的平台的方法、流程和机制，具备自助式、核心逻辑打通开发运维，核心价值可度量局限性各团队重复搭建工具链，能力碎片化核心逻辑沉淀标准化自服务内部开发平台核心价值统一工程底座，组织级赋能局限性缺少AI智能体专属管控、治理能力敏捷开发核心逻辑打破职能竖井，短迭代快速反馈核心价值快速交付局限性运维链路断层核心逻辑线性分阶段交付核心价值流程标准化，文局限性风险后置8的工程工具，无论多么自动化，其范式始终是由人类理解任务、操作工具、解读结果。而AIAgent的引入，正在催生一种新的人机协同范式，人类定义目标与约束，智能体则自主进行任务规划、上下文理解、工具调用与结果生成，最终由人类进行确认与决策。这意味着研发范式的自动化对象发生了根本性转移，传统自动化聚焦于流程、环境和重复性操作的自动化，而智能体自动化则将自动化延伸至认知任务与决策循环。AIAgent的潜力远不止于代码生成助手。它能够作为“数字员工”深入价值流的各个环节，如基于自然语言进行需求分析与规格化、理解代码库上下文并进行重构建议、自动设计测试用例并执行探索性测试、诊断持续集成流水线的失败根因、分析运维监控告警并给出修复建议等。其核心价值在于将人类从大量模式识别、信息检索与初级推理任务中解放出来，聚焦于更高层的架构设计、创造性问题解决与战略决策。在代码生成与理解方面，GitHubCopilot等代码助手已成为数百万开发者的日常工具，更高级的Agent能基于需求文档自动生成模块级代码，或深入理解复杂代码库，回答关于系统逻辑的深度问题。在测试与质量保障方面，Agent可自动生成单元测试、集成测试用例，执行探索性测试，并能智能分析CI流水线失败日志，定位根因并提出修复建议。在运维与可观测性方面，Agent可实时监控告警，自动执行标准化的故障诊断流程，生成事件报告，甚至在预设规则下执行自动化补救操作。在安全审计方面，Agent能持续扫描代码依赖库漏洞，分析配置安全风险，并自动生成修复补丁。这些实践表明，AIAgent不再仅仅是辅助工具，而是具备了承担端到端子任务的能力，将大幅提升研发交付中知识型工作的效率与一致性。2.政策与市场双重驱动智能化研发进入规模化阶段全球范围内，人工智能驱动的生产力变革已成为各国共识，研发范式的智能化转型被主要经济体普遍纳入国家战略优先序列。当前，我国研发范式智能化转型已在政策引导与9市场需求的协同作用下，从早期技术探索阶段进入规模化落地与深度应用的关键时期。国家战略布局持续深化，为研发范式的智能化发展构建了清晰的制度框架与实施路径。2025年8月，国务院印发《关于深入实施“人工智能+”行动的意见》，明确提出“驱动技术研发模式创新和效能提升”“支持智能化研发工具和平台推广应用”。2026年4月，国务院印发《关于推进服务业扩能提质的意见》，进一步要求“深入实施‘人工智能+’行动，加快智能编程工具研发使用，支持采购大模型、智能体服务”。同期，工业和信息化部宣布开展“人工智能+软件”专项行动，加快智能编程研发应用，培育模型即服务、智能体即服务等相关新业态。各地方也正结合自身产业基础，积极探索相关政策落地与实践应用，为智能化研发从技术验证迈向工程化落地提供了明确的制度预期。产业实践层面，企业对研发智能化的价值认知已从概念验证转向实效验证。多份国际权威机构的调研报告从不同维度验证了这一趋势。LangChain基于1340份有效回复的调研显示，57%的受访者已将智能体投入生产环境，大型企业正引领采纳潮流。在员工规模超万人的大型组织中，67%已部署智能体，另有25%1正在开发中。JetBrains2025年对全球194个国家近2.5万名开发者的调查显示，85%的开发者定期使用AI工具进行编码和开发，62%2至少依赖一款AI编程助手或智能体工具，AI编程已变为行业标配。Anthropic联合Material于2026年发布的《智能体现状报告》基于超500位技术领导者的调研显示，编码是目前应用最成熟的领域，近90%的组织都在使用AI辅助编程，高达86%的企业已将其部署于生产环境；更具突破性的是，42%的企业已经信任AI智能体在人类的监督下主导开发工作，而不仅仅是辅助写代码，它的提效已经覆盖了从需求规划1LangChain,StateofAgentEngineering[R/OL].2026./state-of-agent-engin2JetBrains,TheStateofDev/research/2025/10/state-of-developer-ecosystem-（58%）、代码生成（59%）到审查测试（59%）和文档编写（59%）3的全生命周期。3.AIAgent时代的研发范式新命题与驾驭工程的必然性随着AIAgent从辅助工具演变为能够自主执行复杂任务的协同主体，研发范式面临的核心挑战已经发生根本性升级。核心挑战不再局限于实现更高程度的自动化，而是在由人类与智能体构成的混合团队中，确保软件交付过程始终保持可控、可信、可验证与可持续优化。技术演进、产业落地、合规治理三重维度共同催生驾驭工程相关理论与落地体系，成为智能原生研发范式迭代演进的客观必然。技术迭代倒逼工程体系升级。生成式大模型、通用智能体、多模态技术的产业化落地，推动Agent深度介入研发流程，衍生出一系列全新工程命题，如任务意图的精准规格化、高质量上下文持续供给、工具调用权限安全沙箱化、生成产物可信度评估、决策过程可审计、基于反馈实现智能体持续优化，延伸至质量保障验证、成本效能度量、组织集体智能沉淀、人机协同流程重构等关键领域。面对上述诉求，原有的敏捷、DevOps与平台工程框架难以原生适配智能体自主执行带来的不确定性，需要嵌入新的治理层与控制机制，才能在释放智能体效率红利的同时管控风险。驾驭工程的核心在于“在不改变底层LLM模型特性的前提下，通过系统工程引导其成为可控的生产力工具”。产业规模化落地存在刚性缺口。据Gartner预测，到2027年底将有超过40%4的AgenticAI项目面临被取消的风险，核心原因在于成本攀升、业务价值不清晰以及风险管控不足。多数企业的Agent部署依然局限于较窄的容错试水区，完全自主的Agent尚未准备好应对复杂的企业级存量场景。这一困境的根本根源在于缺少覆盖全研发链条的系统3Anthropic,Material.The2026StateofAIAgentsReport[R/OL].2026./hubfs/The%202026%20State%20of%20AI%20Agents%20Report.pdf4Gartner,GartnerPredictsOver40%ofAgenticAIProjectsWillBeCanceledbyEndof2027[R/OL].(2025-06-25)./en/newsroom/press-releasf-agentic-ai-projects-will-be-canceled-化工程支撑。驾驭工程依托全流程管控框架，能够针对性补齐产业工程化落地短板，打通技术原型向商用产品转化的关键链路。行业合规与高质量发展提出新要求。智能软件加速向金融、高端制造、医疗、政务等关键领域渗透，产业发展对程序可信性、运行安全性、业务合规性的约束持续收紧。据德勤《2026年企业AI现状报告》数据显示，只有21%5的组织有成熟的AgenticAI治理模型，包括Agent决策边界、实时监控、行为异常预警、完整审计链路等。传统研发范式的分段式管控模式难以覆盖智能代码生成、智能体自主调度等新增风险环节，亟须依托驾驭工程搭建全链路管控体系，匹配各领域规范化、高质量发展的监管与产业要求。（三）驾驭工程内涵界定与演进路径1.驾驭工程核心理念驾驭工程（HarnessEngineering）中的“Harness”本意为“马具”，即套在马身上用以控制引导的整套器具。Anthropic于2025年11月发布文章《Effectiveharnessesforlong-runningagents》，形成从上下文工程、跨会话连续性到长程任务驾驭设计的完整技术演进链，最终推出旗舰产品ClaudeCode。2026年2月5日，HashiCorp联合创始人MitchellHashimoto在个人博客中首次提出“HarnessEngineering”。原文提到其核心理念为：每当发现智能体犯错时，就花时间设计一个工程化方案，确保它未来不会再犯同样的错误。2026年2月11日，OpenAI发布技术博客《Harnessengineering:leveragingCodexinanagent-firstworld》（驾驭工程：在智能体优先的世界中利用Codex给出关键阐述：人类掌舵，智能体执行。2026年3月，Anthropic在《Harness5Deloitte,2026StateofAIintheEnterprise[R/OL].2026-01./content/dam/assets-zone3/us/en/docs/services/consulting/2026/state-of-ai-2026.pdfdesignforlong-runningapplicationdevelopment》（长运行应用程序开发的驾驭设计）一文中进一步明晰该概念，定义为支撑复杂AI智能体运行的外部框架、控制机制与编排体系，即一套完整的工程化支撑体系。其核心关注点并非单次模型调用，而是Agent完成工程任务所需的完整工作系统，驾驭工程主张对任务进行清晰界定，为执行环节提供完备上下文信息，实现工具调用的权限管控与操作留痕，保障执行环境的安全隔离，完成输出结果的测试验证，做到全流程可审计、投入成本可计量，并推动实践经验的持续沉淀复用。2.从提示工程到驾驭工程的层级跃迁大模型的工程化范式，经历了从提示工程到上下文工程，再到驾驭工程的清晰演进过程。提示词工程聚焦于输入侧优化，通过结构化地组织提示词引导模型，以提升大模型响应的质量。典型实践包括少样本提示、思维链引导、角色设定等，具有明显的单轮、无状态和强经验依赖属性，难以支撑多步骤、跨系统的复杂任务。上下文工程将关注点从单词输入扩展到模型所见的信息流，在推理时动态整合历史交互记录、当前场景参数及外部系统检索信息，为模型构建更完整的决策语境。代表性技术包括检索增强生成、上下文窗口管理、记忆机制设计等。上下文工程在提升模型判断准确性上较提示工程有明显进步，但当任务链条延长、决策节点增多、智能体跨系统自主执行时，因缺乏行为约束与反馈闭环而难以确保任务的可靠完成。驾驭工程的核心从优化模型输入转向构建外部管控体系。相较前两者，驾驭工程的关键差异体现在三个维度。第一，从影响输出质量到保障任务达成，关注的是端到端的工程可靠性而非单点响应效果。第二，从开放生成到受控执行，通过约束机制将智能体行为限定在可预期、可审计的范围内。第三，从人工辅助到自主协同，在人类划定边界的前提下赋予智能体完成复杂长周期任务的自主性。表1大模型工程范式演进阶段提示词工程上下文工程驾驭工程核心问题如何让模型听懂如何提供给模型正确的信息如何让模型行为可控优化方向输入端信息端系统端人类行为教AI说话给AI信息控制AI行为技术代表CoT、Few-shotRAG、向量搜索、长上下文安全沙箱、权限系统、记忆框架本质文字技巧弥补能力不足给模型提供更优质的信息用系统约束代替模型局限性难以规模化复用信息量和质量难以平衡需要大量工程投入（一）意图鸿沟：自然语言到工程任务的转化难题用户与AIAgent的交互起点是自然语言输入，这构成了第一层理解障碍。用户的请求通常模糊且依赖于未明言的上下文，例如，“帮我分析一下这个性能瓶颈”或“研究一下这个需求可能的问题”。此类表述具有口语化和隐含前提的特点，难以直接映射为研发交付所需的精确、可验证的任务规格。工程任务规格必须明确定义目标、输入边界、输出标准、前置依赖、验收条件和风险评估。AIAgent越来越多地被部署到自动化任务中，但往往基于规格不足的用户指令运行。Agent为弥补缺失信息而做出无根据的假设、未能提出澄清性问题，可能导致次优结果、因工具滥用带来的安全风险以及计算资源的浪费。当前Agent在实现明确界定的软件设计计划方面极为高效，但用户意图往往模糊且存在多个同样有效的解决方案。字节跳动TRAE团队在2026年火山引擎Force大会上披露，其选取三个主流编码模型与三个主流智能体框架两两组合，以同一真实中等复杂度需求、相同提示词各运行一百次，仅考察功能是否基本正确时，所有组合正确率均超过80%；但一旦考察界面易用性、可靠性、可维护性、性能、兼容性等工程化维度，得分断崖式下跌，组合间还表现出极强的随机性。这一实验表明，人工智能表面“理解意图”，但实际产出与开发者对工程质量的真实期望之间存在系统性偏离。驾驭工程落地过程中，企业需要定义并实施一套任务规格化流程，将模糊的请求解析为包含明确语义和可验证成果的行动指令，通常涉及三个关键环节：意图识别，通过领域术语库和上下文理解提取用户请求的核心目标；任务规格化，补充缺失的任务参数，定义成功标准与验收路径；意图校准，在任务启动前通过交互确认或与现有工单系统集成，确保Agent理解与用户期望一致。缺乏此类机制，Agent的应用将仅限于低风险、可逆的辅助场景，而无法承担核心工程责任。（二）上下文壁垒：企业知识资产治理与供给短板驾驭工程的有效运行需要实现AIAgent对相关上下文的精准获取，包括需求文档、代码库、接口定义、测试用例、历史缺陷、架构指南及团队成员的经验知识。然而，企业知识资产呈现碎片化、多模态、动态变化的特征。企业AI不缺模型，缺可执行的业务上下文。业务规则、流程标准、审批习惯、交付要求、专家判断、历史经验，这些才决定Agent能不能进入真实工作流。阿里云与亚信科技在Qoder智能体落地大型企业级Java存量项目的联合实践中发现：在代码规模庞大、多条业务链路交织，并依赖RPC（远程过程调用）框架、流程编排引擎、配置中心、分布式缓存等多类中间件的复杂工程场景下，如果仅为智能体配置基础代码检索能力，智能体虽然能够生成语法合规、编码风格统一的代码，却极易产生难以察觉的业务语义偏差。智能体缺少全局工程视角，难以识别跨模块依赖关系、项目长期形成的隐性开发约束；大量业务规则、历史踩坑经验散落在文档、沟通记录与工程师个体经验中，未形成结构化知识资产按需供给智能体，形成典型的上下文壁垒。项目团队依托驾驭工程体系搭建分层上下文工程能力，建设工程知识库、混合语义检索机制、分阶段动态上下文注入策略后，智能体变更引发的隐性业务缺陷得到明显改善。因此，企业必须系统性构建上下文工程的能力，将分散在各系统中的隐性及显性知识，通过向量化、结构化或元数据标注等方式，加工为Agent可高效检索、引用和验证的资产；设计基于语义相似度、任务关联度及权威性权重的混合检索算法，确保返回的上下文集合既相关又精炼；制定动态的上下文注入策略，根据任务类型、阶段及复杂度，决定哪些信息应在任务规划、执行及验证环节被主动提供。一个成熟的上下文工程体系，是实现Agent决策稳定性与结果可预测性的基础设施。（三）交付断层：智能体生成产物验证与证据缺失AIAgent能够快速生成代码、设计稿、测试脚本或分析报告，但这仅仅完成了生成环节。而交付意味着生成物必须经过系统化的验证，达到可集成、可部署、可运维的成熟度标准。代码需要编译通过、符合编码规范并通过单元测试；需求分析需要被相关方评审确认；问题排查结论需要有完整的证据链支持。例如，Datadog在让AI编码智能体构建Redis兼容服务器redis-rust的实践中，智能体在数小时内即生成了一个功能完整的Redis兼容服务器，代码编译通过且基础测试全部通过，但实际部署后暴露出大量隐蔽的正确性缺陷，如错误消息偏离Redis协议兼容性的细节、内存占用达到合理实现的8倍、抽象层过度设计等问题，均非传统编译检查和单元测试所能检出。为解决这一断层，Datadog逐步构建了分层强制验证体系，从基础的行为对比校验，到注入故障路径的模拟测试，再到协议兼容性的形式化验证、数学层面的属性证明，以及多节点分布式环境下的正确性检验。这一实践表明，AI智能体生成软件的速度远超团队验证能力，仅凭编译通过和测试通过远不足以判定产物可交付，必须构建从功能正确性、性能达标、协议兼容到分布式一致性的多层验证证据链，才能转化为可信赖的生产级交付物。因此，落地驾驭工程过程中，企业需要将Agent的工作模式从“对话-应答”升级为“任务-验证-交付”模式。这意味着Agent的输出不应是开放式文本，而应为结构化产物。例如，一个代码生成任务的结果应同时包含：生成的代码、通过的相关测试报告、静态分析扫描结果以及代码变更对现有接口影响的简要分析等。这套证据链使得每一次Agent产出都变得透明、可评估，符合研发交付的质量门禁要求。缺乏证据链的生成，本质上是未完成的半成品，无法直接创造业务价值。（四）安全风险：工具调用与自主执行的治理隐患当Agent作为执行者，能够主动调用Git、Kubernetes、CI/CD流水线、云平台API等工程工具时，风险的性质和级别发生了根本变化。风险从内容安全扩展到系统安全、数据安全和操作安全领域。一次未经授权的gitpush、一个配置错误的云资源创建指令或一个具有提权能力的命令，都可能导致实际的业务中断或安全事件。因此，驾驭工程必须系统地解决以下问题：1.身份与权限。明确Agent应以何种身份访问各系统，并确保其权限遵循最小权限原则；2.操作沙箱化。定义高风险操作清单，确保高风险操作在受控的沙箱环境中先行验证；3.审批与决策。明确哪些操作序列必须引入人工审批环节，并将审批的触发条件和流程与Agent工作流进行集成；4.全链路审计。确保Agent的每一次工具调用、传入参数、返回结果和执行上下文被不可篡改地记录，并能实现完整的行为回放以供事后追溯和根因分析；5.熔断与回滚。当检测到异常行为或误操作时，需要有自动化机制立即终止Agent会话并尝试回滚已造成的变更，需要将安全策略、工具授权、操作审计等能力以平台化的方式嵌入Agent的执行环境，从而对其行为进行系统性约束。（五）效能瓶颈：Token成本管控与价值转化低效随着Agent在企业内规模化部署，模型调用成本将从技术团队的预算细节上升为企业级管理议题。然而，仅关注总Token消耗是片面的，甚至可能导致为避免成本而牺牲必要的上下文深度，进而降低产出质量。Token消耗的规模正在快速膨胀。根据高盛团队2026年研报预测，随着消费者与企业导入AIAgent，全球Token消耗量将在2026至2030年间暴增24倍6。Meta已计划6GoldmanSachsResearch,AIAgentsForecasttoB限制员工Token使用，原因是内部AI使用成本预计达到数十亿美元级别。AT&T、Meta、沃尔玛、亚马逊等巨头也掀起AI预算管控浪潮，企业对员工的考核不再单纯基于Token使用量，而转向对Agent输出结果的评价。更深层次的挑战在于Token的价值转化率。Token消耗的构成直接反映了上游工程实践的效率水平。因此，驾驭工程体系下，企业需要建立一套AI效能度量体系，这包括监控和分析Token消耗的明细模式，建立基于业务价值的效能度量指标，并据此优化上下文工程、任务编排逻辑和工具设计，确保每一分Token的消耗都能创造业务价值。（六）组织断层：个体提效与组织级效能的适配差距AI工具的引入通常始于工程师个体层面的效率提升，例如，更快的代码补全、更便捷的文档生成和更轻松的故障排查等。这种单点提效本身具有价值，但它并不自动等同于组织级交付能力的整体改善。企业的核心目标是缩短端到端的需求交付周期、降低缺陷逃逸率、减少人工返工，并增强发布的可预测性与安全性。尽管个体开发者借助Agent工具能够实现数倍乃至数量级的效率跃迁，但不少投入几十甚至数百万推进AI转型的企业，却在真实落地中频频受挫，并没有体现在显著的组织级效能提升当中。以快手为例，其技术团队在AI提效实践中就遭遇了典型的“组织断层”困境。早在2024年，快手就自研并推广了AI编程工具Kwaipilot，覆盖超万名研发人员，AI代码生成率也达到了30%以上。然而，经过大量调研和数据分析，团队发现了一个反直觉的现象：尽管个人主观体感编码效率提升了20%—40%，但组织整体的需求交付周期和吞吐量却没有明显提升。这一困境的根源在于，仅靠“AI辅助编码”无法改变研发全流程的协作模式。工程师在编码环节节省的时间，往往会被需求评估、联调、测试、发布等2026-05-20./insights/articles/ai-agents-forecast-to-boost-tech-上下游环节的流程阻滞与协同损耗所抵消。个人效率的提升被组织流程的瓶颈所吸收，无法传导为组织效能的整体跃迁。为此，快手在2025年下半年开启了“智能化2.0”的探索，将重心从“提升个人编码效率”转向“提升组织整体效能”。其核心举措是定义并推行一套全新的“AI研发范式”，将需求的AI应用程度划分为L1（AI辅助）、L2（AI协同）和L3（AI自主）三个等级，并配套建设了能支撑多种研发模式的下一代智能研发平台。通过这一系列组织级的系统性变革，快手成功将L2及以上等级的需求占比提升至20%以上，并实现了需求交付周期下降58%的显著成果，真正实现了从“个体提效”向“组织增效”的跨越。因此，企业需要设立专门的AI工程效能团队，负责定义和推广企业内统一的驾驭工程最佳实践模板，构建可共享、可编排的智能工作流，建立连接个体Agent使用行为与组织级交付指标的度量仪表盘，并运营内部的AI能力社区以促进知识分享与持续改进。IDC在《FutureScape2026》中也指出，真正拉开差距的，不是是否引入AI编码工具，而是企业是否具备平台工程、治理能力和开发者角色转型的整体规划。那些仅在局部场景试点智能体的组织，将很难释放规模化价值；而将驾驭工程作为企业级能力来建设的组织，更有可能在速度、质量和创新能力上形成长期优势。（一）研发交付视角下的驾驭工程定义驾驭工程落地的六大落地痛点，横跨人机交互、知识供给、质量治理与组织运营等多个层面，反映出企业在研发场景下引入AI智能体时面临的工程能力缺口。驾驭工程并非零散的工具组合，而是一套有明确内涵与边界的工程体系。立足于研发交付视角，本报告对驾驭工程进行了进一步的系统性界定：驾驭工程是一套用于系统化地约束引导、集成、管理与优化AIAgent，使其能够安全、可靠、高效地融入现有研发范式体系，并最终实现人机协同效能最大化的工程原则、框架与实践集合。作为一种正式的工程范式概念，驾驭工程并非旨在取代敏捷、DevOps或平台工程，而是在此基础上增加一个全新的智能管理层。（二）驾驭工程与其他主流工程体系关联与对比软件研发范式已有的主要工程实践各自诞生于不同的技术发展阶段，解决不同层面的核心问题，同时与驾驭工程存在互补协同关系。DevOps是驾驭工程的重要基础。DevOps的核心目标是让软件交付过程实现自动化、协同化和可度量，缩短从需求到上线的反馈周期。DevOps为驾驭工程提供了研发工具链、流水线、测试、发布、监控和度量的基础设施。在驾驭工程的视角下，DevOps流水线不仅是人工与自动化脚本的执行通道，更是Agent参与工程任务的核心运行环境。平台工程为驾驭工程的企业化落地提供承载方式。平台工程的核心贡献在于将构建、测试、发布、环境、监控、安全、度量等工程能力产品化和自服务化，降低研发团队的认知负荷。Agent协作与治理平台可以被视为平台工程在AIAgent时代的自然延伸，将Agent运行所需的任务调度、上下文管理、工具接入、安全管控等能力统一封装为平台化服务。提示词工程是驾驭工程决策层的一部分。提示词工程聚焦于通过结构化的提示词设计，让模型理解角色、任务、约束、步骤和输出格式。然而，驾驭工程的管控范围远超提示词本身，它不仅管理提示词的编写，还管理提示词动态生成所依赖的任务定义、上下文供给、2l规则约束、工具配置、权限控制和验收标准。上下文工程是驾驭工程感知层的核心能力。上下文工程聚焦于为模型或Agent提供正确、必要、可追溯的任务上下文，避免上下文缺失、污染和浪费。在驾驭工程的体系中，上下文工程被进一步拓展，涵盖知识接入、检索优化、内容裁剪、权限过滤、来源追溯和上下文组装等完整环节。表2各工程体系对比工程体系核心关注点解决的关键问题与驾驭工程的关系DevOps端到端交付自动化缩短需求到上线的反馈周期提供研发工具链、流水线、测试、发布、监控和度量基础平台工程工程能力产品化与自服务化降低认知负荷，统一工程能力为驾驭工程的企业化落地提供平台承载方式提示词工程模型输入优化让模型准确理解任务意图是驾驭工程决策层的组成部分上下文工程信息流管理让模型获得正确的决策信息是驾驭工程感知层的核心能力驾驭工程Agent全生命周期管控让Agent在工程系统中可靠交付系统性整合上述能力，构建完整治理体系22层级核心问题层级核心问题Agent如何执行，执行效果如何层级核心问题Agent怎么做，做了什么层级核心问题Agent是否安全合规层级核心问题系统如何越用越好层级核心问题图2驾驭工程运行五层架构分类和任务规格化，将模糊的自然语言请求转化为结构化的、可执行的工程任务定义。第二是上下文管理能力，负责识别、裁剪和追溯任务所需的上下文信息，确保Agent在正确的时机获取正确的信息。第三是事件感知能力，通过接入拉取请求、需求变更、缺陷报告、持续集成失败、测试失败、发布审批、生产告警等多源事件，并将事件转化为Agent可执行的任务指令。第四是项目工作指南能力，即建立项目级别的Agent工作指南文档（如AGENTS.md或CLAUDE.md明确项目的架构约束、编码规范、技术栈要求和特殊约定，使Agent在执行任务时能够遵循项目特定的工程规范。第五是记忆管理能力，包括短期任务状态的维护和长期项目经验的沉淀，使Agent能够在长周期任务中保持上下文连贯性，并在跨任务执行时复用历史经验。第六是知识工程能力，涵盖知识的接入、清洗、切片、标注、权限绑定、检索和版本管理，将企业碎片化的知识资产转化为Agent可高效利用的结构化知识。2.决策层决策层是驾驭工程体系的中枢神经系统，包含编排和反馈两大核心组件。编排组件负责让Agent基于目标、约束和策略做出正确的计划与判断，反馈组件则负责验证Agent是否真正完成了任务，并记录完整的过程信息以供审计和改进。编排组件的核心能力包括四个方面。策略引擎根据任务风险等级、数据敏感性、权限约束和成本预算等因素，动态决定Agent的执行策略，包括是否需要人工审批、是否允许直接操作生产环境等。模型路由根据任务复杂度、响应延迟要求和成本约束，智能选择最适配的大语言模型，在效果和成本之间取得平衡。任务规划负责将复杂目标拆解为可管理的子任务序列，生成执行计划，并识别潜在的风险点和依赖关系。Agent编排支持单Agent自主决策、多Agent协作和人机协同等多种工作模式。反馈组件的核心能力同样涵盖多个维度。质量验证包括验收标准检查、自动化测试验证、静态代码分析与安全扫描。评估器管理涵盖评价Agent的能力评估、评分标准管理和人工抽检机制。日志与追踪记录工具调用日志、Agent决策链路和审计日志。成本度量包括Token消耗监控、单任务成本核算和成本异常告警。证据管理负责证据包的自动生成和结果的可追溯性保障。3.执行层执行层负责让Agent通过受控的工具和环境完成真实的工程行动。这一层的核心原则是：Agent不应直接拥有无限的系统权限，而应通过受控工具网关和隔离环境执行任务。这一设计确保了Agent的执行行为始终处于可监控、可约束、可回滚的状态。执行层的核心能力包括五个方面。Skill管理涵盖Skill的注册、调用和复用，使Agent的最佳实践能够被封装为可重用的能力单元。工具接入通过工具网关统一接入各类工具，包括MCP协议工具、API工具和脚本工具，并实施细粒度的权限控制。工程环境管理提供沙箱环境和临时工作区，确保Agent的代码执行、测试运行和脚本操作在隔离环境中进行，避免对生产系统造成影响。工程操作能力涵盖代码操作、流水线操作和测试执行等核心研发活动。状态管理则支持长程任务的状态跟踪、执行记录管理和断点续传等能力。4.安全与治理层安全与治理层负责确保Agent在安全约束下运行，贯穿AI工作的全过程。当Agent从辅助工具演变为能够自主调用工程工具、操作生产系统的执行主体时，安全治理尤为重要。安全治理层需要覆盖以下十个核心安全能力维度：表3安全治理层能力维度安全能力核心说明Agent身份管理明确Agent以什么身份访问代码、数据、工具和环境，建立Agent身份认证体系数据权限控制控制Agent可读取的需求、代码、日志、文档和生产数据的范围敏感信息保护防止密钥、账号、客户隐私、生产数据进入模型上下文或输出结果工具调用授权控制Agent能否写文件、提交代码、运行命令、触发流水线、访问数据库高危操作审批对发布、数据库变更、生产操作、核心业务逻辑修改实施人工确认机制沙箱隔离确保Agent在隔离环境中运行代码、测试和脚本安全验证对Agent产物进行安全扫描、依赖扫描、权限检查和合规检查审计追踪记录Agent读取、调用、修改和审批的完整行为链路行为回放支持复盘Agent完整行为路径，定位越权、误操作或错误决策风险分级根据任务类型、数据敏感性和操作影响范围划分风险等级安全治理层的设计应遵循纵深防御原则，即在Agent运行链路的每一个节点都设置相应的安全检查点。从Agent接收任务时的身份验证和数据权限检查，到执行过程中的工具调用授权和沙箱隔离，再到任务完成后的安全扫描和行为审计，形成多层次的安全防护网。同时，安全策略应具备动态调整能力，能够根据任务风险等级和环境变化自动提升或降低安全约束的严格程度。5.持续进化层持续进化层负责让驾驭工程体系基于运行数据持续优化。这一层的核心理念是：驾驭工程的目标不是让某一次任务成功，而是让Agent团队和驾驭工程体系本身越用越好。持续进化层的核心能力涵盖六个方面。一是失败模式分析，包括失败分类、Trace分析和根因定位，将每一次失败转化为可学习的经验。二是提示词优化，包括提示词效果评测、参数调优和优质提示词的沉淀复用。三是知识优化，包括知识补全、知识质量治理和项目指南的持续更新，确保知识库与实际工程环境保持同步。四是Skill优化，即基于执行数据评估Skill效果并持续改进。五是策略优化，包括模型选择策略和工具调用策略的动态调优。六是运营度量，从Agent资产运营和价值效果评估两个维度，为管理决策提供数据支撑。持续进化层的有效运转依赖于高质量运行数据的持续积累。每一次Agent执行的任务输入、上下文来源、模型调用参数、工具调用链路、输出结果、验证反馈和用户评价，都应被完整记录并纳入分析体系。通过对这些数据的系统性分析，企业能够识别Agent能力的薄弱环节、知识资产的缺口、工具配置的优化空间以及策略参数的改进方向，从而实现驾驭工程体系的螺旋式上升。（一）企业驾驭工程落地实施原则企业落地驾驭工程不宜一开始追求全流程自动化，而应遵循循序渐进、风险可控、价值导向的基本原则。基于行业实践经验，本节提炼出四项核心落地原则，为企业系统化推进驾驭工程建设提供指导。1.选取合适场景进行试点驾驭工程的落地应从合适的试点场景切入，通过小范围验证积累经验和信心，再逐步扩展至更大范围。适合优先选择的场景通常具备四个特征：任务频率较高，能够产生规模化的效率收益；结果有明确的验证规则，能够通过自动化测试或人工评审客观评估Agent产出质量；操作风险相对可控，即使Agent执行出现偏差也不会造成严重的生产事故或业务损失；有一定的数据和知识积累，Agent能够获取完成任务所需的上下文信息。典型的试点场景包括代码评审辅助、持续集成失败分析、发布检查清单执行、缺陷根因分析等。例如，去哪儿旅行在Harness实践中选择异常修复作为优先试点场景，该场景任务发生频率高，结果可通过编译状态、部署状态和callback回写状态客观验证，操作范围限制在修复分支内且禁止master提交和forcepush，风险相对可控，同时具备代码仓库、编译系统、部署平台、日志平台等丰富的系统和数据积累，符合试点场景选择的典型特征。申万宏源选择测试用例生成作为试点场景，该场景结果可通过用例综合得分、测试点准确率、人工修正占比等指标进行量化验证，且具备业务手册、需求文档等领域知识基础，具备较高的可验证性和上下文可得性。试点场景的选择应建立在系统化的评估框架之上。企业可从以下五个维度进行综合评判：高频性维度评估该任务是否频繁发生，是否具有规模化应用价值；可验证性维度评估结果是否能通过测试、规则、人工评审或业务数据进行客观验证；上下文可得性维度评估Agent是否能获得完成任务所需的知识和数据；工具可接入性维度评估所需系统和工具是否可以通过接口、MCP协议（模型上下文协议）或脚本进行接入；价值可度量性维度评估是否能够度量效率、质量、成本、安全或业务价值的改善幅度。表4试点场景选择评估维度评估维度核心判断问题高频性该任务是否频繁发生，是否具有规模化价值可验证性结果是否能通过测试、规则、人工评审或业务数据进行验证上下文可得性Agent是否能获得完成任务所需的知识和数据工具可接入性所需系统和工具是否可以通过接口、MCP或脚本接入价值可度量性是否能度量效率、质量、成本、安全或业务价值的改善2.明确人与AI的职责边界企业在引入Agent之前，必须明确界定人与AI在各业务场景中的职责边界。这一边界的核心问题是：在特定任务中，人类应以何种方式参与Agent的决策和执行过程。行业实践中形成了两种基本模式：“人在环内”（Human-in-the-Loop）模式，即人类在Agent决策的关键节点进行实时审核和确认；“人在环上”（Human-on-the-Loop）模式，即人类在Agent运行过程中进行监控，仅在检测到异常时介入干预。职责边界的划分应综合考虑三个因素。一是任务的风险等级，高风险任务应采用人在环内模式，低风险任务可采用人在环上模式。二是Agent的能力成熟度，对于经过充分验证且表现稳定的Agent，可以逐步放宽人类介入的频率和深度。三是业务的合规要求，某些行业法规可能明确要求特定操作必须经过人工确认。职责边界的设定不是一成不变的，而应随着Agent能力的提升和经验的积累进行动态调整。例如，银河证券在UserHarness实践中明确将CodingAgent定位为执行者而非替代研发责任主体的自主决策者，人类仍对业务目标、关键架构、安全合规、合并与发布承连续5次修复失败后触发人工介入，单测覆盖率动作级护栏对未识别的命令默认询问，通过权限配置明确允许、拒绝和需确认的操作；流程级护栏在代码安全环节通过安全扫描子Agent调用安全扫描工具，加载security-scan-analyzer技能分析报告并对高危漏洞自动修复；发版门禁通过release-material-checker技能对上线功能清单、需求文档、安全扫描报告、测试报告等发版物料进行校验，形成了从操作到流程再到发布的纵深防御体系。建议企业将Agent应用场景划分为三个风险等级。低风险场景包括代码补全建议、文档生成、测试用例设计等，这些场景的错误产出影响范围有限且易于纠正，可以允许Agent在较宽松的约束下运行。中风险场景包括代码审查意见生成、持续集成失败分析、缺陷诊断等，这些场景的错误产出可能导致决策偏差或返工，需要设置适当的质量检查和人工抽检机制。高风险场景包括生产环境变更执行、数据库结构修改、安全策略调整等，这些场景的错误产出可能直接导致业务中断或安全事故，必须实施严格的人工审批和操作审计机制。4.建立度量与价值评估机制企业落地驾驭工程不应仅统计模型调用次数、Token消耗量、生成代码行数或生成用例数量等表层指标，这些指标虽然能够反映Agent的活动规模，但无法真实衡量其对业务价值的贡献。企业应建立一套多维度的价值评估体系，涵盖产出质量、效能提升、安全风险、成本价值等多个维度，以真实衡量Agent应用带来的有效价值。例如，在产出质量维度，应关注产物采纳率、人工修改比例、测试通过率和缺陷发现率等。在效率提升维度，应关注任务周期缩短、发布频率提升和平均修复时间改善等。在安全与风险维度，应关注缺陷逃逸率变化、安全事件发生次数和合规检查通过率等。在成本与价值维度，应关注单任务成本、高价值场景Token占比和Agent的复用率等。3l知识方案后达到83分，较基线提升33.9分；同时从测试点准确率(由30%提升至97%)、人工修正占比(由约73%降至约7%)等维度进行持续度量。策略、知识库、识别研发痛点、度量指标接入模型网关、工具网关、上下文服务、安全护栏选择高频低风险场景，验证Agent执行能力扩展到更多研发场景与团队图4驾驭工程落地六步实施路径短期（3至6个月）、中期（6至12个月）和长期（1至2年）的实施路线图。关键交付物包括现状评估报告、能力差距分析和分阶段实施计划。2.第二步：基础设施搭建搭建驾驭工程所需的基础设施，包括模型接入网关（LLMGateway）、工具接入网关（ToolGateway）、上下文服务（ContextService）和沙箱执行环境。模型接入网关统一管理部门内所有大模型的接入、路由和调用治理；工具接入网关实现对代码仓库、需求平台、测试系统、监控平台等工具的标准化接入和权限管控；上下文服务负责根据任务需求动态组织和供给企业知识；沙箱环境为Agent提供安全隔离的代码执行和测试空间。3.第三步：试点场景落地选择1至3个符合试点标准的场景进行落地实施。在这一阶段，重点验证驾驭工程基础架构的可用性、Agent工作流的可靠性以及安全管控机制的有效性。每个试点场景都应明确定义任务规格、验收标准、安全约束和度量指标，并建立完整的执行记录和经验总结机制。试点过程中应特别关注Agent的错误模式，将其作为优化驾驭工程配置的重要输入。4.第四步：效果评估与经验沉淀对试点场景的实施效果进行系统性评估，对照预设的度量指标分析实际成效。评估应同时关注定量指标（如效率提升幅度、质量改善数据、成本节约情况等）和定性指标（如团队满意度、工作模式变化、协作效率改善等）。在此基础上，提炼可复用的最佳实践，包括Agent配置模板、提示词模板、知识库建设规范和安全管理策略等，形成标准化的经验资产。5.第五步：规模化扩展在试点验证充分的基础上，按照既定的优先级逐步将驾驭工程能力扩展至更多场景和团队。扩展过程中应重点关注以下方面：建立场景化的Agent配置模板库，降低新场景的接入成本；构建企业级的知识资产治理体系，确保知识库的质量和时效性；完善安全管控策略，适应不同场景的差异化安全需求；建立跨团队的Agent运营机制，促进经验共享和能力复用。6.第六步：持续优化与能力进化建立驾驭工程的持续优化机制，基于运行数据的持续积累驱动Agent能力和工程体系的螺旋式上升。这一阶段的核心工作包括：建立常态化的Agent能力评测体系，定期评估各场景Agent的表现并识别改进方向；运营知识资产的持续更新和质量治理流程，优化模型选择策略和成本控制策略；沉淀和推广高质量的Skill和提示词模板；培养企业内部的驾驭工程专业人才队伍。（三）实践场景地图基于驾驭工程的五层能力架构和软件研发全生命周期的各阶段特征，本报告梳理了典型实践场景地图。该场景地图按照研发流程阶段进行组织，涵盖从需求分析到运维保障的完整链条。在需求分析阶段，典型场景包括需求规格化辅助、需求一致性检查和需求影响分析。在编码开发阶段，典型场景包括代码生成与补全、代码审查辅助、代码重构建议和技术文档生成。在测试阶段，典型场景包括测试用例生成、探索性测试执行、缺陷分析辅助和测试覆盖率优化。在持续集成与交付阶段，典型场景包括持续集成失败分析、发布检查与准图5驾驭工程实践场景地图验证、部署执行、日志分析、异常修复和结果汇报等完整工程链路。在真实企业研发环境中，AI研发面临的主要挑战包括以下方面：一是流程链路长。一次AI研发任务需经过平台建任务、Runtime拉取代码、AIAgent修改代码、执行编译、提交分支、触发部署、等待状态、抓取日志、分析异常、回写平台状态等多个环节，任一环节不稳定都会导致任务失败。二是系统依赖复杂。真实研发问题通常横跨Git仓库、编译系统、CI/CD平台、发布平台、环境管理平台、日志平台、链路追踪平台、知识库等多个企业系统。AI若仅能在IDE或单次对话中工作，难以处理跨系统证据链问题。三是上下文不可控。研发任务中的代码、日志、构建结果、部署记录、trace信息和历史经验体量庞大，直接输入模型会导致上下文膨胀、重点遗漏或推理不稳定。尤其是大日志和长链路执行记录，缺乏摘要、索引和结构化产物支撑时，AI难以持续推理。四是质量和风险难以保障。AI自动修改代码后可能出现编译失败、改错分支、误提交、误部署、破坏主干、误判异常、忽略环境问题等风险。缺乏流程约束、安全护栏、编译验证和部署反馈机制的情况下，AI研发难以进入生产级研发流程。五是端到端验证困难。传统本地调试仅能验证Controller、脚本或单个工具调用，无法验证完整AI研发任务是否能够从需求提交稳定走到代码修改、分支推送和平台状态回写。线上依赖Jenkins、飞书、OSS（对象存储服务）等外部系统，调试慢、成本高且易产生副作用。综上，该实践的核心痛点可概括为：AI研发的关键瓶颈不在于缺少具备代码生成能力的模型，而在于缺少一套能够让AI在真实研发现场安全、稳定、可复现、可观测工作的工程化Harness体系。2.Agent任务定义该实践中的AIAgent定位为面向企业研发流程的自动化执行者和协同研发参与者，核心职责是围绕真实研发任务完成从问题理解到代码交付的闭环。具体任务职责包括以下方面：第一，理解研发任务和问题上下文。Agent根据用户需求、异常堆栈、构建失败信息、部署失败记录、日志内容、trace信息和知识库内容，判断当前任务所属类型（需求开发、异常修复、CI/CD修复、部署问题、环境问题或知识问答等）。第二，调用研发工具和企业系统。Agent通过Skills和脚本调用真实研发系统，包括代码仓库、编译工具、部署平台、日志平台、链路追踪系统、环境管理系统和知识库等。第三，完成代码分析与修改。在确认问题属于代码缺陷或研发需求后，Agent定位相关代码，生成修复方案，修改代码，并配合本地编译或平台编译进行验证。第四，推动验证与交付流程。Agent在Harness约束下执行编译、提交分支、推送代码、触发部署、等待状态、抓取失败日志、分析失败原因等操作，并在必要时进入下一轮修复。第五，沉淀结构化结果。Agent的输出不仅包括自然语言解释，还形成可供系统、开发者和后续Agent继续使用的结构化产物，例如JSON、summary、mapping、日志索引、修复说明、提交信息和部署结果等。第六，在边界内自动化执行。Agent的自动化范围在明确规则下完成可控动作，例如，37多源任务输入多源任务输入AIAgent工作流◎理解任务◎调用工具◎修改代码◎验证交付◎沉淀结果◎自动执行任务类型识别●需求开发●Bug修复●部署问题●环境问题●知识问答研发工具体系●日志●知识库Harness安全边界(允许∨/禁止x)结构化输出图6去哪儿旅行AICodingHarness实践整体流程图综上，该实践中AlAgent的任务定义可概括为：在Harness提供的流程、工具、规0101Skill契约层触发条件|参数要求|禁止动作|输出格式|失败处理02脚本执行层API调用|状态轮询|日志下载|编译部署|结果解析03证据工作区Records|Logs|Mapping|Summary|ResultJSON04流程编排层多个小Skill串联任务分析、代码修改、验证与再修复05安全护栏层分支限制|权限约束|危险动作禁止|外部副作用关闭06状态机与闭环层Callback回写|DB状态更新|统一状态码|等待终态07本机端到端验证层真实Agent|真实Git|真实Callback|本地任务隔离安全、稳定、可恢复的AI研发自动化闭环Harness图7去哪儿旅行AICodingHarness设计方案第三层是证据工作区。研发任务中的关键产物如执行记录、日志、mapping（索引映射）、summary（摘要）、resultJSON（结构化结果文件）、sessionsummary（会话摘要）等统一落盘。AI采用“读summary和索引，再按需深挖原始日志”的策略，降低上下文成本，同时支持后续步骤从文件恢复上下文。第四层是流程编排层。复杂研发任务由多个小Skill串联完成，而非依赖一个超大工具包。例如，异常修复场景可串联异常分类、环境探测、源分支部署校验、代码修复、本地编译、提交推送、部署验证、失败日志抓取和再分析等步骤。每个Skill负责清晰边界，上层流程负责组织闭环。第五层是安全护栏与规则配置。Harness明确允许自动化的动作范围与限制条件，典型规则包括：禁止master提交、禁止删除远程分支、禁止forcepush（强制推送）、禁止mergecommit（合并提交）、限制推送目标分支、禁止自动补高风险参数、外部副作用默认关闭等。对于本机闭环验证，避免触发真实Jenkins、飞书通知、OSS上传和异常查询调用。第六层是状态机与闭环判断。AI研发任务以真实平台状态为完成标准，而非进程是否退出。Runtime完成后通过callback（回调接口）回写Console（任务控制台Console根据callback更新DB（数据库）状态，最终进入success或failed状态。编译、部署、环境创建等过程均有统一状态码和轮询机制。第七层是本机端到端闭环验证。为降低对线上Jenkins的依赖，Harness将AI研发链路收敛到本机可运行闭环。Console生成Runtime执行命令，本机进程拉起Runtime；Runtime仍使用真实AIAgent、真实Git仓库、真实callback；任务通过本地queueId、本地分支和固定日志路径进行识别与排查。下：AlAl项目助手Center工作流编排文件系统版本发布中间件平台本地CodingAgent飞书QPaw天弦webuiAgent编排skills管理Jira联调平台sandbox质量门禁测试平台图8去哪儿旅行天弦平台整体架构图4l第一，研发流程可闭环。AI不再仅生成代码片段，而是可进入从需求或异常输入到代码修改、编译验证、分支推送、部署反馈和结果汇报的完整链路。任务完成状态通过callback、DB状态、Git分支、编译结果和部署状态共同确认，而非主观判断。第二，研发自动化稳定性提升。通过Skill契约、脚本执行、状态机、结构化输出和失败续跑机制，AI研发流程从“模型临时发挥”转变为“有步骤、有状态、有证据、有终态”的工程流程。即使部分日志下载失败、网络请求失败或部署失败，也可通过重试、分支处理和日志再分析继续推进。第三，问题定位和复现能力增强。所有关键动作均有结构化产物落盘，任务可通过日志、summary、callback状态和Git分支进行复盘。本机闭环验证使得AI研发任务不再完全依赖线上Jenkins黑盒，开发者和AIAgent均可在本机复现完整链路。第四，上下文和模型成本降低。通过证据压缩、summary优先、mapping索引和按需深挖大日志，AI无需每次读取全部原始日志和长session记录，既减少上下文污染，也降低模型调用成本，提高分析稳定性。第五，安全性和可控性提升。通过Githooks、分支限制、禁止高风险操作、外部副作用隔离、任务标识和执行超时控制，AI可在真实研发系统中工作，同时降低破坏主干、误触生产系统或造成不可控副作用的风险。第六，为后续规模化AI研发平台打下基础。高频研发动作可逐步包装为小Skill，统一参数、状态码和输出文件；跨Skill的workspace（工作区）规范可让编译、部署、日志、修复共享同一证据目录；长期可形成可审计、可回放、可统计、可评估的AI研发流水线。从定性角度看，AI研发从“辅助写代码工具”推进至“可进入企业研发流程的工程化Agent”。从定量角度，后续可围绕以下指标评估成效：AI任务成功率、编译通过率、部署成功率、异常修复闭环成功率、平均任务耗时、人工介入次数、失败复现耗时、日志分析耗时、模型调用成本、端到端自动化占比等。5.经验总结第一，AI研发的关键在于为模型构建可执行、可验证、可审计的工程现场。真实研发问题依赖大量企业系统和半结构化证据，只有将这些系统转化为AI可靠调用的工具面，AI才能真正进入研发流程。第二，Prompt与程序需各司其职。Prompt适合表达目标、策略和判断原则，但不适合承载复杂流程控制、状态轮询、参数解析和失败恢复。确定性动作应交由脚本和Harness处理，AI负责解释、取舍和生成修复方案。第三，单个Skill应保持清晰边界。触发、查询、下载、分析、修复、部署、状态轮询不应混在一个超大工具中。小Skill更易于测试、复用、组合和治理，也更适合形成跨场景的研发自动化资产。第四，所有外部系统交互均需工程契约。不应让模型临时拼接复杂API，也不应让模型自由访问系统。参数、权限、状态码、输出格式、失败处理、日志路径和回调协议均需保持稳定，才能形成可复现流程。第五，证据链比一次性上下文更重要。研发现场的日志、构建记录、部署结果和trace信息往往体量庞大，不宜直接输入模型。更优方式是先生成summary和mapping，再按需读取原始证据，让AI分阶段推理。第六，安全边界须为硬护栏而非提示词提醒。禁止master提交、禁止forcepush、禁止删除远程分支、限制目标分支、关闭外部副作用、控制并发和超时等，均应在工具和脚本层实现，而非仅依赖模型指令。第七，闭环验证须以真实结果为准。进程退出不代表任务成功，模型输出也不代表修复完成。真正的完成标准应是编译通过、分支推送成功、部署状态成功、callback回写成功、DB状态更新成功、用户可见结果一致。后续优化方向包括：统一不同Skill的workspace规范；沉淀跨任务的证据复用和失败归因机制；构建更完整的成本、质量、风险和人工介入数据运营看板；增强复杂任务的自动规划、智能路由、实时质检和降智处理能力。最终目标是推动AI研发平台从“能自动完成一些研发动作”升级为“可规模化、可治理、可评估的AI研发流程平台”。（二）中国银河证券股份有限公司：银河证券面向研发全流程的UserHarnessEngineering实践1.实践场景痛点银河证券在推动AICoding从个人辅助工具走向组织级研发能力的过程中，应用场景已从代码补全延伸到需求理解、规格编制、计划拆解、编码测试、代码评审、合并和流水线协作。但金融业务系统对正确性、可追溯性、安全与合规有更高要求，仅依赖模型能力或CodingAgent的内建能力，难以保证不同人员、不同项目和不同工具下的稳定产出。主要痛点如下：一是上下文分散。需求位于ONES、代码位于GitLab、构建与质量结果位于蓝鲸DevOps等平台；研发人员需要反复切换系统，Agent也难以获得完整、连续的任务上下文。二是规则未显式化。架构约束、分支规范、测试方法、评审标准和敏感操作边界常依赖个人经验，AI首次执行时容易遗漏关键条件。三是反馈感知过晚。测试、静态扫描、流水线问题往往在生成之后甚至合并前才被发现，人工审核承担了大量可前置、可自动化的纠错工作。四是能力难以复用。提示词、修复经验和评审结论分散在个人会话中，换项目、换工具或换人员后难以继承，组织无法形成持续增强的工程能力。上述问题的本质并非模型能力不足，而是用户侧缺少一套围绕具体系统构建的控制结构：即在行动前给出足够的引导，在行动后提供可驱动自修正的反馈。2.Agent任务定义在银河证券的AICoding实践中，CodingAgent被定义为UserHarness中的执行者，而非替代研发责任主体的自主决策者。Agent在明确的上下文、规则、工具权限和质量反馈范围内完成任务，人类仍对业务目标、关键架构、安全合规、合并与发布承担最终责任，具体任务包括以下方面：第一，获取并整理需求上下文。通过MCP读取任务、关联资料和迭代信息，形成可供后续执行复用的任务上下文。第二，将模糊需求