工信部《"人工智能+软件"专项行动实施方案》要求推动软件开发由「人工编写」向「人机协同」转变，中国信通院 10 月 16 日发布的《驾驭工程：赋能智能原生软件工程研究报告（2026年）》把四类痛点与六大核心能力讲清楚了。核心结论是——智能体参与研发之后，管控对象从确定性程序变成自主决策系统，必须在模型之外重建一层约束与反馈机制。
2026 年 10 月有两件事把「AI 怎么写代码」这个问题从工具层推到了工程治理层。
一件来自标准侧。工业和信息化部印发的《"人工智能+软件"专项行动实施方案》明确了一个转变方向：推动软件开发由"人工编写"向"人机协同"、软件产品由"被动响应"向"主动执行"、软件服务由"产品交付"向"价值交付"转变。据《中国电子报》2026 年 10 月 13 日的报道，该方案以"应用牵引、创新驱动、安全可控、生态协同"为原则，部署了六方面十九项重点任务。据《经济日报》同期的报道，方案提出到 2028 年推广应用覆盖 2 万家规模以上软件企业、累计组织实施 100 项软件企业智能化技改项目、在重点行业打造 100 个智能体软件标杆应用、孵化 5 个以上优质开源项目。工信部信息技术发展司副司长王威伟在解读时提到，智能编程工具已贯穿需求分析、代码生成、测试运维等开发全流程。
另一件来自研究侧。据今日头条 2026 年 10 月 16 日 14:42 的报道，中国信息通信研究院云计算与数字化研究所近日发布《驾驭工程：赋能智能原生软件工程研究报告（2026年）》。报告把智能体在研发中的四类痛点写得很直接——可控性不足、跨系统协同难、安全边界模糊、成效难量化；并提出驾驭工程（Harness Engineering）是"面向智能体构建约束与反馈闭环的系统工程方法"，承载统筹协同、规范治理、效率提升、安全保障四大职能。
把这两件事放在一起，结论只有一句：智能体参与研发之后，团队的管控对象从"确定性的程序"变成了"自主决策的系统"，旧的那套流程管控适配不了，必须在模型之外重建一层约束与反馈机制。
这条线与本站已发布的几篇不重复：代码评审怎么做才有效讲的是人工评审的分工与粒度；AI Agent 可观测性与评测讲的是运行期怎么追链路、怎么判成功；AI Agent 运行时隔离讲的是执行侧的四道边界；本文讲的是把这几件事组织成一套完整的研发管控框架——从接入、编排、循环到安全、效能、评估，以及这个框架在 2026 年下半年的行业实践水位。
---
传统的软件工程管控，建立在一个隐含前提上：执行流程的代码是确定性的。同样输入必然同样输出，代码在版本控制里，变更可 diff，行为可预测。因此只要管住"谁提交了什么、走没走评审、测试过没过"这三件事，产出质量就是可控的。
智能体打破了这个前提。据 Munder Difflin 在 2026 年 10 月 16 日汇总的发布追踪，Claude Code 在 2.1.296 版本加入了"工作流模型固定"（workflow model pinning），允许开发者把特定模型锁定到特定工作步骤；同一天的 v2.1.301 又加入了无人值守重试模式下的用量上限等待参数。这些功能指向同一件事：智能体已经能在没有人逐步盯着的情况下连续工作数小时，决策路径由模型在运行时生成，而不是由人预先写死。
这就是信通院报告里"软件研发管控对象从确定性程序变为自主决策智能体"这句话的技术含义。当产出物不再完全由人决定，管控的重心就必须从"审核产出"前移到"约束过程"。
信通院报告把痛点归为四类，这四类恰好对应四种不同的工程解法，值得逐条拆开看。
可控性不足，指的是没人能准确预测智能体会做什么、做到哪一步。这一类的解法是编排与约束：把大任务拆到足够细、给每一步明确的完成判据、把不允许做的事写进规则文件。
跨系统协同难，指的是智能体接不进已有的工单、代码库、CI、文档体系。这一类的解法是连接：先做工程系统的 MCP 友好改造（接口定义清晰、权限模型细粒度、调用日志可观测），再谈智能体。
安全边界模糊，指的是智能体的权限范围与人的权限范围没有清晰的接缝。这一类的解法是授权与隔离：把授权做在模型之外，用操作系统级的沙箱而不是提示词里的叮嘱。
成效难量化，指的是生成量涨了但交付价值没涨。这一类的解法是评估与效能：指标必须锚在"被接受的变更"上，而不是"生成的行数"上。
这四类解法在后面第五节会分别展开。这里先记住一个判断：它们不能互相替代。只做安全不做编排，智能体会安全地做错事；只做编排不做评估，你会得到一套看起来很规范、但不知道有没有变快的流程。
信通院报告引用的两个比例值得单独记住：截至 2026 年 5 月，67.3% 的软件企业已将 AI 投入生产，31.2% 完成智能体与核心流程内嵌部署。
这两个数字需要正确解读，否则容易得出错误结论。67.3% 是"投入生产"，指的是有 AI 能力在真实环境里跑起来；31.2% 是"与核心流程内嵌部署"，指的是它进了主链路而非边缘试验。两者之间 36 个百分点的差距，说明多数企业跨过的是"用起来"的门槛，还没跨过"嵌进去"的门槛。
从工程视角看，这 36.1 个百分点对应的正是上面四类痛点。把智能体接进主链路意味着它开始改动真实代码、调用真实工具、影响真实发布——可控性、安全边界与成效量化这三类问题会同时暴露。所以 31.2% 这个数字更像是行业能力分布的真实刻度，而不是一个需要追赶的目标值。
另外两组来自产业侧的数据可以放在一起看：据《经济日报》2026 年 10 月 14 日报道，截至 2026 年 6 月我国日均词元调用量已突破 500 万亿；2025 年软件业务收入 154831 亿元，同比增长 13.2%。调用量的增速与收入增速并不同步，这本身就说明了单价的下降与渗透的加深——对研发团队的现实含义是，用量不再是一个稀缺约束，约束正在从"能不能用上模型"转向"能不能管住模型"。
---
信通院报告给出的定义是：驾驭工程是面向智能体构建约束与反馈闭环的系统工程方法。它为智能体构建运行环境、约束规则与反馈机制。
社区侧对同一概念的解释可以把这个抽象定义落到具体部件上。据 lpqz.cn 在 2026 年关于驾驭工程的梳理，Harness 这个词本意指马具——马很有力，但得靠缰绳、轭具、车厢把它约束到正确方向上，力气才能变成有效输出。放到 AI 编程里，Harness 指的就是模型之外、帮助智能体可靠工作的所有外层机制。该站给出的拆解公式是：Coding Agent = Model + Context + Tools + Constraints + Feedback + Human Control，其中只有 Model 在模型内，其余五项构成 Harness。
这个公式同时划清了三个常被混用的概念的层级关系：
| 层次 | 解决的问题 | 典型载体 |
|---|---|---|
| 提示工程 | 你对模型说什么 | 提示词模板 |
| 上下文工程 | 模型能看到什么 | 上下文装配与裁剪 |
| 驾驭工程 | 智能体在什么信息、什么权限、什么时候被 review、谁能拍板的条件下干活 | 规则文件、契约、沙箱、审批闸、审计轨迹 |
三者不是替代关系，而是分层叠加。这也解释了为什么单靠提示词技巧无法解决管控问题——提示词解决的是"说什么"，而管控要解决的是"在什么条件下允许它做什么"。
信通院报告提出驾驭工程有六项核心能力：连接、编排、循环、效能、安全、评估优化。它们分层协同，贯通智能体与外部系统语义互通、长任务过程控制、自主循环迭代、安全审计、效能优化与评估迭代的技术全链路。
拆到工程动作上，这六项各自对应一组具体工作：
连接，解决语义互通。产出物是清晰定义的接口、细粒度的权限模型、可观测的调用日志。前提是现有系统先做过 MCP 友好改造。
编排，解决长任务的粒度与上下文分配。核心问题是任务拆到多细、每步携带多少上下文。这里有个反直觉但被反复验证的结论：粒度越细，完成质量越高。
循环，解决自主迭代的收敛性。产出物是"规划 → 执行 → 验证 → 修复"的闭环，且验证失败要能自动定位并重新进入验证。
安全，解决边界问题。核心原则是授权必须在模型之外强制，提示词指令不构成安全边界。
效能，解决成本与吞吐。产出物是按任务分级的模型调度与算力预算。
评估优化，解决成效衡量。产出物是分层的评测集与回归机制。
报告在此基础上构建了 L1 到 L5 的能力成熟度模型，沿工具接入、运行底座、治理闭环、协同自治到规模生产逐级演进，为企业提供可评可验的建设路径。
这个分级的实用价值在于它给出了下一步该做什么的判断依据。多数团队卡在 L1 到 L2 之间：工具接上了（能调用 IDE、能跑测试），但运行底座没建（没有沙箱、没有审计轨迹）。往 L3 走的标志不是"用了更多工具"，而是"治理闭环"成立——每一次智能体的动作都有记录，每一次越界都有阻断，每一次偏差都能被复盘。
报告另外提到，成熟度模型的迭代治理要求与实施误区是独立章节，说明分级不是一次性评估，而是需要持续复评的过程。这一点与工程现实一致：管控框架的松弛通常不是设计时就有的，而是在一次次"这次先放行"的例外里形成的。
信通院报告展望驾驭工程将历经标准形成、平台化、基础设施化三阶段，最终迈向智能软件底层基础设施。随着规模化推进，单点技术创新红利消退，产业竞争转而聚焦 AI 治理。
组织层面，报告判断团队作业方式与角色分工会被重构：AI 承接代码生成、测试编写、基础运维等标准化工作，工程师转向需求设计、风险研判与场景创新。流程层面，安全合规以架构约束层嵌入研发全流程，从外部的周期性要求转为原生的常态属性。技术层面，跨平台互操作标准逐步统一。
这三个"转向"里，对团队结构影响最大的是第一个。它意味着能力要求的两端会同时抬高——需要把需求说清楚的人，和需要判断产出是否合理的人，都会变得更值钱；而中间层的纯执行角色承压。
---
信通院报告判断"随着全球驾驭工程应用层工具能力趋同，差异化空间收窄，竞争焦点转向底层框架"。这个判断在 2026 年 10 月中旬的公开信息里能看到具体痕迹。
海外侧，据信通院报告梳理，Anthropic 等率先完成工业级验证并形成商业产品矩阵，OpenAI 于 2026 年 8 月开源 Codex Harness，谷歌、微软等厂商同步推进，形成多家并行的竞争态势。
国内侧，报告显示华为 AgentArts 长程任务完成率 80%，DeepSeek 开源 Harness 框架 24 小时获约 5.5 万星，填补了国内驾驭框架的开源空白。需要说明的是，这两个数字均为报告引用的厂商与项目方口径，"长程任务完成率 80%"未披露任务集定义，"5.5 万星"是开源社区的实时关注度指标而非生产可用性指标，两者都不构成独立第三方评测结论。
开源工程侧，一个值得关注的项目是 AWS Labs 的 AI-DLC Workflows。据 pivotnews.ai 报道，该仓库于 2026 年 10 月 15 日出现在 Hacker News，版本标记为 2.11.0，采用 MIT-0 许可，列出 Claude Code、Kiro CLI、Kiro IDE、Codex CLI、Cursor、opencode、GitHub Copilot 七种编程智能体为支持的 harness，底层是单一 harness-neutral 核心。
据 explainx.ai 的整理，该项目的 README 自述包含 5 个阶段、33 个 stage、14 个 agent（11 个领域专家、2 个评审与 1 个自适应编排器）、11 个工作流 profile，以及 119 类事件的审计轨迹；每个 stage 都设有人工审批闸，并把人工修正转成持久化的行为规则。需要说明的是，这些数字来自项目自身文档，explainx.ai 明确标注"我们没有全部实际运行这些，计数来自 README，请视为项目自述"，FollowAgents 的评估则给出 49/100 的分数并指出存在重大缺口。
这个项目的意义不在于可以直接照搬，而在于它示范了一件重要的事：同一套工作流定义可以跨七种编程智能体运行，引擎保持确定性。对同时使用多种工具的团队，这意味着"换工具"不等于"换流程"——这一点对正在标准化研发流程的组织有直接的工程价值。
另一个来自社区侧的例子是 OpenClaw Codex Agent。据觉醒学院 2026 年 10 月 13 日的介绍，这是一个 MIT 协议的契约优先 AI 编程工作流：第一步不是让 AI 动手，而是把任务目标、验收标准、边界条件落成规格文档；随后是规划、执行、验证、修复四步闭环，验证失败时 AI 自动定位并修复再进入下一轮验证，整个循环每一步都留日志，修复环节数量被日志显式记录。
这个项目在 2026 年 10 月 16 日的 Hacker News 榜单中被 Munder Difflin 收录时已被描述为 4000 星量级。同一份 10 月 16 日的汇总还提到，CopilotKit 发布了 CLiF，把生产环境的智能体 trace 与用户动作转成可复用技能、回归评测套件与微调数据集；据 MarkTechPost 的报道，这套机制的价值在于把用户辅助过的真实运行记录编译成回归用例，而不是手工编写合成测试。
把这些放在一起看，2026 年 10 月中旬的共同信号是：工具层的模型可用性已经不再是瓶颈，差异化正在转移到工作流的约束、验证与审计机制上。
---
连接的难点通常不在智能体侧，而在既有系统没有面向智能体的接口契约。这件事的顺序很关键——先盘点接口，确定哪些值得开放，优先挑读取类、查询类、可逆且低风险的动作；再按清晰接口定义、细粒度权限模型、可观测调用日志三条要求做改造。
顺序之所以重要，是因为接口标准化的收益在跨部门协作时才兑现，而改动成本随时间单调上升。先用私有接口实现的试点，在需要对接外部系统时改造成本远高于一开始就按标准封装。同时要同步建立管理规范，包括服务命名规则、版本控制、权限范围与数据访问边界。
协议层选型可参考MCP 与 A2A 有什么区别：前者解决智能体如何纵向调用工具与数据源，后者解决智能体如何横向发现同行并委派任务，两者是分层共存而非二选一。
任务粒度与产出质量强相关。 据 hqwc.cn 转载的 AI 原生研发实践记录，一个反直觉但被反复验证的结论是：粒度粗的任务智能体容易"放飞自我"，粒度细到"改哪个方法、按什么顺序、签名保持不变、补上对应测试"这一级时，完成质量会明显提升一个档次。这项实践里，任务拆分环节投入了较多精力，但规则的制定者是人，AI 负责配合分解。
上下文裁剪是这件事里最核心的工程问题。 同一份记录指出，上下文越长模型的理解准确率越低、token 成本越高，同一个代码库里智能体根本不需要把整个仓库塞进上下文。做法是基于代码索引做"定向提取"——智能体接任务时只携带相关模块的代码片段、接口定义、数据库 schema 与相关文档。这套机制跑顺之后，生成代码的"跑题率"明显下降。
这两点合起来对应信通院六大能力里的"编排"：编排放的不是工作流图，是上下文分配方案。
在编程智能体上，最有价值的机制之一是把 AI 最弱的"自信而静默的偏移"变成最便宜的一个信号：一个失败的测试。
据 DEV Community 上 Ayonaryan 的实践记录，其做法是为接口写可执行契约——契约是一道围栏，智能体可以在围栏内快速跑，一旦漂移出去，契约就会大声失败。他给出的经验总结是："让生成的产出在无人检查的情况下运行是这两道护栏的共同原则。"
他记录了一次真实的效果验证：开启生成式负向测试后，契约测试对登录请求做了变异——空 body、username 为 null / 数字 / 布尔——并期望返回 4xx。结果 14 个负向测试失败，因为接口对这些畸形输入全部返回了 200：它没有输入校验，而是把畸形请求体静默当成了一次登录失败处理。补上 body 校验（body 非对象或字段非字符串时返回 400）、补上文档、重跑后 24/24 全绿。
更值得注意的是第二部分：他们给智能体调用的那个 LLM 的 /v1/chat/completions 也写了契约，用桩（stub）替换真实模型，使 AI 路径在 CI 中离线、确定性、零 token 消耗。然后用真实代码路径跑完整契约套件，结果暴露出五个原本靠读代码发现不了的问题——其中一个接口泄露了未文档化的配置对象（数据库路径与主机），被契约当作"未知属性"抓了出来；另一个接口在非字符串命令下崩溃返回 500 而非 400；还有一处契约把设计写错了（标记为必填的 body，在人工确认流程里其实是可空的），说明契约本身也需要跟实际设计对齐。
这个案例的价值不在于工具选型，而在于它示范了一个可迁移的原则：契约必须可执行，才能把约束变成信号；AI 依赖也必须可替换，才能让 AI 路径进入常规测试。
需要补充的是，这类契约测试在无智能体的传统开发里同样有效——提升知识库问答准确率里讲的"拒答策略"与本文讲的"契约阻断"在工程形态上一脉相承，都是把边界条件显式化成可自动检查的断言，而不是写成文档提醒别人注意。
这一项在本站的AI Agent 运行时隔离怎么做里已展开过四道边界（身份、权限、网络、执行），这里只补一个与编程智能体直接相关的落地细节：沙箱应该由操作系统强制，而不是由模型自觉。
Codex CLI 的实现方式是一个可参照的样本。据 codexal.co 2026 年的整理，Codex 的沙箱由操作系统强制执行——macOS 上是 Apple Seatbelt，Linux 上是 Landlock 与 seccomp。这条设计原则被明确表述为：一个困惑的模型、或一个被它读到的文本操纵过的模型，仍然无法写到边界之外。
配套的是审批策略的三档划分：untrusted 在任何已知安全命令集之外的动作前都要问，适合从未见过的仓库；on-request 是合理默认值，沙箱内自由工作，需要越过边界（比如访问网络或写出工作区）时才问；never 从不提示，Codex 的非交互模式强制要求这一档，因为它所替代的正是本该由沙箱承担的职责。
codexal.co 给出的多数开发者适用组合是：approval_policy = "on-request" 配合 sandbox_mode = "workspace-write" 且关闭网络访问。这个组合的语义是：智能体平时不打扰你，但出不了项目目录、从网上装东西之前必须问你——而这正是你希望被咨询的那一刻。
同一份资料还给了一条值得警惕的提醒：每个智能体工具都有一个能同时关掉审批与沙箱的"一键放开"开关。在一台持有 SSH 密钥、云凭证与浏览器配置的主机上运行它，意味着一条错误的命令——或一条被污染的指令——会以你的完整用户权限执行。它的建议是：想要不受限的自主性，就用隔离去换（容器、一次性虚拟机或云端运行环境），绝不要用主力工作站换。
这一条与信通院报告"安全边界模糊"这条痛点完全对应：边界模糊的本质，是把授权寄托在一个概率性组件的自我报告上。
这一条来自 2026 年 8 月 14 日一场 AI Coding 圆桌讨论的公开记录。据该场讨论中李渭宁的表述，质量体系其实一直没变过——单元测试通过率、覆盖率、发布频次、P1/P2 生产事故数量，这些指标跟用什么工具不相关。AI 到来之后的变化是"怎么给 AI Coding 加上工程护栏，让它能符合一直沿用的质量体系"，主要从三方面着手：
一是输入输出侧。需求通过规格生成代码时，以前写在 user story 里的 case / when / then 要继续沿用；代码规范不管用规则文件还是用规格描述出来都要写清楚——以前是人看文档，现在改成让 AI 读规格去做代码生成；依赖管理要严格，不能随便下载外部包，只能在内部仓库取，第三方组件有安全漏洞就被禁掉，要不断升级版本。
二是持续改进侧。像 PDCA 一样，每次生成完去看差距在哪里，然后不断改进。
他在同一场讨论里给出的一个判断值得引用：质量要求是越来越高的，跟用什么工具不相关；不管用人、找外包还是用 AI，一定要达到那个指标——比如生产平均故障率有多少、发布次数有多少，不看生成多少行代码。
同一场讨论里林香鑫提到的另一个视角是多智能体分工：不同阶段有不同上下文需求，如果以单一智能体把全流程规则全灌进去，就会出现混淆和上下文爆炸问题；他们因此提出多智能体，给不同智能体不同职责，前端做前端、后端做后端、需求做需求、评审做评审。她也提出了"Token 刺客"这个说法——有些技能包会持续占用上下文，你不知道它占用了多少，token 就哗哗地花出去了。
这一段的实务含义是：智能体带来的是速度，但速度本身不是指标。 如果不事先把指标锚在交付结果上，团队很容易在没有基线的情况下接受"看起来快了"的印象。评估体系的细节可参考AI Agent 可观测性与评测中关于成功定义与分层打分的方法。
关于效能，有一份 2026 年的工程组织指南给出了几条具体到可执行的判断，其中一条特别值得强调：人工评审负荷是应当被当作有限资源对待的。
该指南指出，如果 AI 增加了变更提案的数量，评审队列与集成环境就会成为瓶颈；因此应当鼓励更小、更可测试、归属清晰的变更，并拒绝那些仅仅因为"生成起来便宜"就接受的大规模智能体重构。它还提示，模型生成的代码仍然是代码——它必须满足契约、测试、可维护性约束与运维预期；变更在几秒内生成出来，并不降低理解其影响面的需要。
该指南给出的评审包内容也值得照做：一个有用的评审材料包应包含任务来源、变更文件、测试结果、值得注意的假设，以及已知缺口；并且必须说清哪些检查实际执行过、哪些只是建议执行。它明确表示"一份精美的总结不能替代可检视的 diff 和可验证的构建输出"。
在度量层面，该指南给出了一个具体建议：把在同类仓库中采样的有边界维护任务，分成允许 AI 与常规流程两组对比，在开工之前就记录任务复杂度与例外情况，并使用固定的完成定义（如"被接受的变更 + 通过的检查"）；若团队自行选择分组方式，需标注该研究为观察性研究。它同时提醒，并行智能体会让时间核算变复杂——经过时间、工程师注意力时间与算力时间是三种不同的量，应当分别记录。
关于该指南提到的一个厂商侧动作：GitHub 在 2026 年 6 月的公告中描述了针对受支持的第三方智能体所创建代码的 CodeQL、依赖与密钥检查。指南本身对此的措辞值得照抄——"这记录的是一项产品能力，不是组织成效改善的独立证明"，团队仍需在自己的仓库里测试这些控制覆盖了什么、遗漏了什么。
---
把前面四节的实践压缩成可复用的形态，大致是三类载体。
这是投入最低、见效最快的一类。据 aiagentmemory.org 在 2026 年 10 月 13 日核对的 Codex 文档，AGENTS.md 是放在仓库根目录、每次运行开始时被读取的 Markdown 指令文件，它决定了你面对的是"猜你规范的智能体"还是"遵守你规范的智能体"。该站的一句判断相当直接：几乎每一条"AI 老是把事情做错"的抱怨，背后都是一份缺失或敷衍的 AGENTS.md。
加载规则有明确机制，值得写进团队规范：全局层级读 AGENTS.override.md（若存在）否则 AGENTS.md，这一层只取第一个非空文件；项目层级从仓库根目录向下走到当前目录，每层检查 AGENTS.override.md → AGENTS.md → 配置的备用文件名，每目录最多取一个；多份文件按从根到当前的顺序合并，更靠近工作目录的文件在冲突时优先；合并后总量上限默认 32 KiB，可通过 project_doc_max_bytes 调整。
"更近的优先"这条规则有一个直接的工程用途：支付、权限、数据同步、部署脚本这类目录可以放更严格的补充说明，而不必污染根目录那份通用文件。
内容上，codexal.co 归纳了一个实用样本，认为有四个板块承担主要作用：命令（让智能体能验证自己的工作）、项目地图（让它不去编辑生成的文件）、约定（让 diff 看起来像你们的代码库）、以及"永远不要做"清单（让影响范围同时被文档和沙箱限制）。
那份样本里"永远不要做"的具体内容值得注意：不执行 git push 或会重写历史的操作；不手工编辑 public/ 下标注为自动生成的目录；不向任何页面添加第三方 CDN 脚本；不改动 .env、密钥配置或任何匹配 *.key 的文件。同站给出的建议是把 AGENTS.md 当代码对待——在 PR 里评审它，约定变了就更新它，每次智能体做错一件事就往里加一条。并提到一个观察：一个 AGENTS.md 有五十次提交记录的仓库，才是一个智能体工作得好的仓库。
OpenAI 官方对此的表述可以作为边界说明。据 aiagentmemory.org 引述官方文档的说法：必须遵守的团队指引要放在 AGENTS.md 或签入的文档里，而记忆（memories）应当被当作辅助的召回层，而不是唯一规则来源。该站进一步区分了两层——指令是你写并提交的规则，记忆是智能体在后台从过去的对话里构建的、默认关闭的召回层。
这条区分很重要：规则必须是人写的、可评审的、版本化的；召回可以是自动的。 两者混同，就等于把管控权交给了不可审计的系统行为。
此外，AWS Labs 的 AI-DLC 展示了另一种更重的形态——把整套阶段化工作流、审批闸与审计轨迹做成 harness-neutral 核心，再为七种编程智能体各做一层适配。轻的一端是单个规则文件，重的一端是完整的工作流引擎，团队应当按治理要求与工具数量选，而不是一律上最重的。
也就是 4.3 节讲的可执行契约。它的定位很清楚：契约是围栏，智能体在围栏内可以高速运行，越界时立刻失败。
落地时的三个要点：
一是契约要覆盖输入侧。用生成式负向测试去变异请求（空值、类型错误、缺字段），期望得到明确的错误码。Ayonaryan 的记录里，14 个失败的负向测试直接暴露了一个被静默吞掉的输入校验缺失——这类问题在功能测试里几乎不可能被发现，因为正常路径本来就通。
二是契约要覆盖 AI 依赖。给智能体调用的模型接口也写一份契约，用桩替换真实模型，让 AI 路径在 CI 里离线、确定性、零成本。这一步是把"AI 路径"从不可测变成可测的关键。
三是契约本身要被校验。Ayonaryan 的记录里，契约把一处设计写错了（把实际可空的 body 标记为必填），这提醒我们契约是一份需要跟设计同步演进的活文档，把它提交进版本控制并纳入评审。
据 hqwc.cn 转载的实践记录，有一条做法被形容为"很反直觉但很重要"：很多团队为了追求效率让智能体一路自动写到底，结果代码库变成一锅粥；该团队坚持在三个节点必须人工介入——涉及数据库变更的、涉及核心支付或安全逻辑的、涉及对外 API 契约修改的。这三个节点上，任何智能体的建议都只是参考，必须由资深工程师签字。
这三个节点的共同特征是不可轻易回滚：数据库变更的代价在生产环境显现，支付与安全逻辑的错误会直接造成资金或数据损失，而对外 API 契约一旦发布就形成了对调用方的承诺。
这条与 AI-DLC 的每个 stage 审批闸、Codex 的 on-request 审批策略在设计意图上是同一件事：自主性应该按可回滚性分级授予，而不是一律给或一律不给。
---
综合信通院报告的成熟度模型迭代治理要求与实施误区章节，以及上面梳理的各方实践，下面这张表里的每一条都有对应的现实表现。
| 常见做法 | 实际后果 | 应有的替代 |
|---|---|---|
| 把驾驭工程理解为"换个更强的模型" | 模型升级后旧问题原样复现 | 约束与反馈机制建在模型之外 |
| 用一份规则文件覆盖所有阶段与所有目录 | 上下文冲突、关键约束被淹没 | 分层文件 + 就近覆盖 + 总量上限 |
| 规则文件写口号不写事实 | 执行不稳定 | 写具体命令、路径、禁止项 |
| 把智能体记忆当作唯一规则来源 | 规则不可审计、不可评审 | 规则人写并版本化，记忆只做召回 |
| 只在文档里写"禁止修改"，不做技术阻断 | 文档形同虚设 | 沙箱 + 权限 + 越界即阻断 |
| 用"生成的行数/提交数"衡量效能 | 指标涨了价值没涨 | 锚在"被接受的变更 + 通过的检查" |
| 让智能体一路自动写到底 | 代码库腐化，责任无法定位 | 按可回滚性设人工签字节点 |
| 依赖随便从公网拉 | 引入带漏洞的第三方组件 | 内部仓库白名单 + 版本升级机制 |
| 沿用"运行全部测试"作为唯一验证 | 耗时长、失败原因难辨 | 按改动范围分层测试 |
| 复核时间放在结果出来后 | 发现时已付出返工成本 | 每个 stage 停在审批闸前 |
| 为了不限自主性而关掉沙箱与审批 | 一条错误命令即以完整权限执行 | 用容器或一次性环境换自主性 |
| 上线后不复核规则文件是否仍然准确 | 约束与现状脱节 | 每次做错一件事就补一条，定期复评 |
这十二条里，前四条指向概念误读，中间四条指向执行形式主义，最后四条指向治理的持续性缺失。它们的共同点是：都不是能力问题，而是"把管控写在哪里"的问题。
---
2026 年 10 月的两份材料——工信部的《"人工智能+软件"专项行动实施方案》和中国信通院云大所的《驾驭工程：赋能智能原生软件工程研究报告（2026年）》——把同一个判断推到了台面上：软件研发正在从"人工编写"走向"人机协同"，而人机协同的瓶颈不在模型能力，而在模型之外有没有一层可靠的约束与反馈机制。
对企业的现实含义不是"要不要全面上 AI 编程"，而是一批今天就能做的具体动作：把团队规范写成可版本化、可评审、智能体每次都会读的文件；把边界条件写成可执行的契约，让违规变成一个失败的测试；把授权做在模型之外，用操作系统强制的沙箱而不是提示词里的叮嘱；按可回滚性给自主性分级，在数据库变更、核心支付与安全逻辑、对外 API 契约这三个节点保留人工签字；把效能指标锚在"被接受的变更"而不是"生成的行数"上；并且承认人工评审负荷是有限资源，大规模智能体重构不应仅仅因为生成便宜就被接受。
这些动作有一个共同特点：它们全部发生在模型之外。模型会升级、基准会变、价格会降，但沙箱、契约、审批闸、审计轨迹与版本化的规则文件不会自己变松。
关于配套的工程能力，可一并参考本站的工程与质量保障与交付流程；涉及验收口径的制定，可看数字化项目的验收标准怎么定；需要在项目启动前把边界问清楚，可参考需求诊断清单。需要针对具体研发场景讨论智能体管控方案，可查看软件研发与人工智能应用开发服务说明，或通过行业解决方案了解分行业的落地要点。
需要说明的是，本文引用的规范文件条款、报告数据与企业实践均来自公开报道与公开项目文档。厂商与项目方的自述数据（如华为 AgentArts 的长程任务完成率、DeepSeek 框架的关注度、AWS Labs AI-DLC 的阶段与审计事件计数）已在文中标明来源，属项目方或厂商口径，不代表独立第三方验证结论；引用 Codex 沙箱与审批策略、AGENTS.md 加载规则时，依据的是 2026 年 10 月第三方核对 OpenAI 官方文档后的整理，具体行为可能随版本变化，落地前请以当期官方文档为准。团队成员在政务监管、集团信息化与行业垂直产品项目中参与过研发流程与质量管控相关模块的研发，但本文不涉及任何具体客户信息。
按中国信通院云大所《驾驭工程：赋能智能原生软件工程研究报告（2026年）》的定义，驾驭工程是面向智能体构建约束与反馈闭环的系统工程方法，它为智能体构建运行环境、约束规则与反馈机制，承载统筹协同、规范治理、效率提升、安全保障四大职能。社区侧的解释更具体：Harness 指模型之外、帮助智能体可靠工作的所有外层机制，可拆成 Coding Agent = Model + Context + Tools + Constraints + Feedback + Human Control，其中只有 Model 在模型内。与提示工程、上下文工程的关系是分层叠加而非替代——提示工程解决「对模型说什么」，上下文工程解决「模型能看到什么」，驾驭工程解决「智能体在什么权限、什么时候被 review、谁能拍板的条件下干活」。
信通院报告把痛点归为四类，分别对应四种解法：可控性不足（智能体自主工作数小时，没人能预测它做到哪一步），靠编排与约束解决——把任务拆细、给每步明确完成判据、把禁止项写成规则文件；跨系统协同难（接不进既有工单、代码库、CI），靠连接解决——先做工程系统的 MCP 友好改造；安全边界模糊（智能体与人的权限没有清晰接缝），靠授权与隔离解决——把授权做在模型之外，用操作系统强制的沙箱；成效难量化（生成量涨了但交付价值没涨），靠评估与效能解决——指标锚在「被接受的变更」而非「生成的行数」。这四类解法不能互相替代：只做安全不做编排，智能体会安全地做错事。
先说加载机制。据 2026 年 10 月第三方核对 OpenAI 官方文档后的整理，Codex 每次运行开始时读取该文件：全局层读 AGENTS.override.md（若存在）否则 AGENTS.md；项目层从仓库根目录向下走到当前目录，每层每目录最多取一个文件，按从根到当前顺序合并，更靠近工作目录的文件在冲突时优先，合并后总量上限默认 32 KiB（可用 project_doc_max_bytes 调整）。内容上通常四个板块承担主要作用：命令（让智能体能验证自己的工作）、项目地图（让它不去编辑生成的文件）、约定（让 diff 看起来像你们的代码库）、以及「永远不要做」清单。关键原则是写具体事实不写口号——不要写「保持优雅」，要写「不要执行 git push」「不要手工编辑标注为自动生成的目录」「不要改动密钥配置文件」。最后，把 AGENTS.md 当代码对待：在 PR 里评审它，每次智能体做错一件事就往里加一条。
它把 AI 最弱的一环——自信而静默的偏移——变成最便宜的一个信号：一个失败的测试。据 DEV Community 上 Ayonaryan 的实践记录，他的做法是为接口写可执行契约，契约是一道围栏，智能体在围栏内高速运行，一旦漂移出去契约就大声失败。实测效果：开启生成式负向测试后，契约对登录请求做变异（空 body、username 为 null / 数字 / 布尔）并期望返回 4xx，结果 14 个负向测试失败——因为接口对这些畸形输入全部返回 200，把畸形请求体静默当成登录失败处理；补上校验后 24/24 全绿。更进一步的第二步是给智能体调用的 LLM 接口也写契约并用桩替换真实模型，让 AI 路径在 CI 中离线、确定性、零 token，然后用真实代码路径跑完整套件，又暴露出五个原本靠读代码发现不了的问题，包括一个接口泄露了未文档化的配置对象（数据库路径与主机）。落地要点有三个：契约要覆盖输入侧的负向变异、要覆盖 AI 依赖、并且契约本身要提交进版本控制纳入评审。
核心原则是按可回滚性分级授予，而不是一律给或一律不给。据实践记录中一条被形容为「很反直觉但很重要」的做法：很多团队为了追求效率让智能体一路自动写到底，结果代码库变成一锅粥；而坚持在三个节点必须人工介入——涉及数据库变更的、涉及核心支付或安全逻辑的、涉及对外 API 契约修改的，且这三个节点上智能体的建议只是参考，必须由资深工程师签字。这三个节点的共同特征是不可轻易回滚：数据库变更的代价在生产环境显现，支付与安全逻辑的错误直接造成资金或数据损失，对外 API 契约一旦发布就形成了对调用方的承诺。同一思路在工具侧也有对应实现：Codex 的审批策略分 untrusted / on-request / never 三档，官方推荐的多数开发者组合是 on-request 配合 workspace-write 沙箱并关闭网络访问——智能体平时不打扰你，但出不了项目目录、从网上装东西之前必须问你。
关键是不能用生成量代替交付价值。指标本身不随工具改变——单元测试通过率、覆盖率、发布频次、P1/P2 生产事故数量，这些跟用什么工具无关；AI 带来的变化只是「怎么给它加工程护栏，让它符合一直沿用的质量体系」。原话是「质量要求是越来越高的，跟用什么工具不相关；不管用人、找外包还是用 AI，一定要达到那个指标——不看生成多少行代码」。如果要自己验证，方法是把同类仓库中有边界的维护任务分成允许 AI 与常规流程两组对比，在开工之前就记录任务复杂度与例外情况，用固定完成定义（被接受的变更加上通过的检查），自行选组的要标注为观察性研究。另外注意并行智能体会让时间核算变复杂——经过时间、工程师注意力时间、算力时间是三种不同的量，应分别记录。最后，人工评审负荷是有限资源：AI 增加变更提案数量后，评审队列与集成环境会成为瓶颈，应鼓励更小、更可测试的变更，不要仅仅因为生成便宜就接受大规模智能体重构。