当 Agent 开始参与企业业务研发，承担需求拆解、业务配置与实现、质量校验等任务，工具链要解决的问题也随之变化：单次业务系统操作成功，如何保证整条研发任务链路正确？长任务中的业务状态偏差和上下文失真，如何发现并恢复？业务操作权限如何随风险受控开放？一次任务中的修正，又如何成为下一次可复用的经验？这些问题涉及业务系统接口、Agent 运行时和治理机制，需要在平台层统一处理。

我们的实践从配置驱动转向意图驱动：用户表达业务目标，系统结合专家知识生成方案，通过低代码 Harness 编排执行。工具主要封装企业业务系统的操作能力，研发工具链将这些能力组织成可执行、可校验的任务流程。底座围绕四条主线建设：业务操作工具协议化与能力原子化、Agent 运行时工程化、上下文工程平台化，以及摩擦信号驱动的改进闭环。

这套架构以“AI 的操作系统”为定位，重点是减少任务执行中的不确定性。输入侧通过知识、规则和上下文收敛方案；输出侧让用户看懂执行过程、判断结果是否可信，并能直接修改。权限、审计、评测和人工审批贯穿其中，支持 Agent 在受控范围内逐步承担更多工作。

目前已覆盖需求拆解、业务配置与实现、质量校验等核心链路。本次分享将结合实际案例，讨论业务操作工具的粒度、低代码 Harness、上下文治理与人机分工的设计取舍，以及如何把执行中的失败和用户修正沉淀为平台规则与可复用的经验，让同类任务少踩一次坑。

演讲提纲

1. 问题：从完成一次任务，到稳定支撑研发流程
   • 单次业务系统操作成功不代表研发任务完成，跨系统执行需要校验业务约束与结果一致性
   • 长任务中的上下文失真、状态偏差和失败重试，会放大局部错误
   • 如何统一管理不同 Agent 的权限、审批与恢复机制，让跨系统任务始终处于受控范围？
   • 如何将单次任务中的用户修正转化为可复用的经验，减少同类错误？
2. 架构：以“AI 的操作系统”为定位，围绕任务降熵建设底座
   • 业务操作工具协议化与能力原子化
     • 通过统一工具协议封装企业业务系统的操作能力，按业务语义划分边界，保持能力正交，并明确重试与幂等约束。一个工具对应一项能说清楚、能校验结果的业务操作
     • 工具描述采用“动作 / 输入 / 输出 / 用例”四段式，写清业务对象、操作前置条件、影响范围与结果状态，显式声明副作用
     • 业务操作粒度不宜一味拆细：过粗会隐藏业务判断和变更范围，过细又会增加跨系统调用、上下文负担和中间失败点
   • Agent 运行时工程化与低代码 Harness
     • Harness 统一承接业务操作工具召回、Prompt 组装、任务状态机、Hooks、执行观测与回放，避免每个业务场景重复搭建执行逻辑
     • 用低代码方式组织任务执行与扩展点配置，降低业务团队组合能力、接入 Agent 的成本
     • 打通低代码流程与代码实现，兼顾业务侧的易用性与研发侧的灵活性
     • 讨论取舍：哪些能力由平台统一约束，哪些允许业务扩展；低代码覆盖到哪里，什么时候需要进入代码层
   • 上下文工程平台化：输入侧减少歧义
     • 专家知识库为意图理解和方案生成提供业务依据；规则支持按业务、渠道和场景配置，在任务各环节引导执行
     • 上下文管理优先保证信噪比，围绕当前任务组织业务规则、配置与系统状态，通过分层缓存、结构化切分与上下文预算管理控制信息规模
     • 区分当前任务状态、业务规则与个人记忆，避免过时的业务配置或个人偏好被当成当前系统事实
   • 治理贯穿执行过程
     • 将权限控制、审计和评测纳入运行时，根据任务风险与验证结果逐步扩大自动执行范围
     • 在授权范围内，低风险、可恢复的操作可自动执行；高风险或不可逆变更需人工确认
     • Harness 统一管理自动执行与人工介入的边界，通过 Hooks 在关键步骤触发校验或人工确认
3. 评测与人机分工：让用户看得懂、信得过、改得动
   • 看得懂：呈现业务方案、目标系统、流程节点和关键配置，让用户知道系统准备执行哪些操作
   • 信得过：让业务约束、校验结果与执行记录可检查。自建场景化 Eval Set，结合 LLM-as-Judge 评估方案与结果；确定性约束仍由程序校验
   • 改得动：用户可以调整业务配置、流程节点和必要的代码，不必因为一个局部错误重跑整个任务
4. 摩擦驱动自进化：把失败与修正变成可复用的经验
   • 高价值信号来自任务跑不顺的地方：用户打断、业务操作连续失败、任务卡死，以及用户对方案和配置的修改
   • 闭环：在明确数据使用范围与留存边界的前提下，采集必要的执行记录与反馈 → 串联任务过程 → 判断问题来源 → 提炼规则 → 评测验证 → 写回 Harness，按风险灰度生效
   • 共性的执行问题由 Harness 统一处理，业务差异通过规则和 Skill 扩展，经过验证的经验再沉淀为可复用能力
   • 知识复利：让经过验证的经验跨任务、跨团队复用，持续改善后续执行
5. 下一步：把平台经验沉淀成研发协议族
   • 协议沉淀：将业务操作工具协议、上下文协议、Harness 扩展点协议和审计协议沉淀为内部研发 AI 协议族，支持跨团队复用
   • 知识沉淀：从研发任务的操作记录与反馈中提炼经过验证的规则、模板和案例，形成可复用的内部知识资产
   • 开放共建：平台保留协议与治理，能力组合权交给一线业务团队；通过低代码 Harness 和可配置规则承接不同场景
   • 验证端到端提效、接入成本和复用效果

听众收益

• 了解企业研发 Agent 底座的设计思路，掌握业务操作工具拆分、低代码 Harness 编排与上下文管理的关键取舍
• 学习 Agent 任务的质量校验与人机分工方法，通过权限、评测和人工审批，让执行过程可检查、结果可修改
• 掌握从执行失败和用户修正中提炼经验的方法，通过规则沉淀、评测验证与灰度应用，减少同类任务的重复错误

AI Coding 工具能力持续迭代，但存在三大天然局限：缺乏企业私域认知（工程规范、业务上下文、共享依赖关系）、上下文窗口容量有限、生成结果具有概率性误差。当这类工具应用于缺少历史文档、技术栈碎片化、代码规模达几十万行的存量系统时，会暴露出全仓扫描 Token 消耗过高、同一功能实现风格不统一、修改一处引发关联故障、代码与文档不同步、研发过程不可追溯等诸多问题。这些问题无法通过模型工具的升级解决——根源不在模型侧，而在企业侧的知识与治理体系。

ADD（Asset-Driven Development，资产驱动开发）的核心思路，是将企业私域知识结构化为两套与代码同仓管理的资产：Framework 层的「技术宪法」明确「代码应当如何编写」的统一规范；Endpoint 层的「四件套」（时序、规则、不变量、索引）清晰定义「每个端点当前的业务逻辑」，且每个环节都绑定代码锚点。在此基础上，通过三套工作流（WorkFlow）定义 AI 在工程初始化、端点梳理、日常开发三大场景下的执行流程与禁行规则，并以单需求五阶段交付件归档机制，保障全流程可审计、可追溯。

本次分享将围绕三大阶段展开：第一阶段聚焦单个需求的精准交付；第二阶段通过架构度量，将目标从「功能实现正确」升级为「系统结构健康」，避免 AI 的快速交付异化为技术债的快速累积；第三阶段从资产驱动开发延伸至资产驱动测试与可执行流程，最终实现「需求输入、代码输出」的端到端自动化交付。分享会明确每个阶段的落地成果、推进路径与实践踩坑经验。

演讲提纲

1. 为什么工具能力升级仍不足以解决核心问题
   • AI Coding 的三大天然局限：私域知识缺失、上下文容量受限、生成结果概率性误差，及其与大型存量系统现状的叠加效应
   • 上下文压缩的恶性循环：系统规模越大，AI 越容易丢失关键上下文
   • 核心结论：问题根源在企业侧，解决方案也必须构建在企业侧
2. ADD 框架全景：三套工作流、两类资产、一套交付体系
   • 两类核心资产：Framework 层按领域拆分的「技术宪法」（覆盖 Web 层、数据访问、消息队列、缓存、日志等领域，非功能约束内嵌于各专题）；Endpoint 层以 API、MQ 消费、定时任务为入口的「四件套」，配套全局统一的业务对象类图与接口契约
   • 全链路可追溯：从接口契约到时序步骤、代码锚点，再到业务规则与不变量，支持正向推导与反向溯源
   • 四方角色协同与四条核心铁律：改代码必同步更新资产、新增端点必先构建资产、修改共享组件必做影响分析
3. 第一阶段：单个需求的精准交付
   • 五阶段工作流：资产检索（仅读取资产、不扫描全量代码）、影响范围分析、资产前置变更、代码实现、双向校验
   • 跨端点涟漪分析：共享组件索引在梳理阶段自动维护，当引用端点数量超阈值时自动暂停，触发人工确认
   • 资产先行机制：先输出资产变更差异供人工确认意图，再执行代码修改；资产变更的审查成本远低于代码变更
   • 人机协同机制：确认节点设置原则、校验脚本与 Git Hook 的兜底方案、交付件归档如何支持会话中断后的续接
   • 降本提效原理：将开放式生成转化为「查表+填空」的确定性推理，同时明确 ADD 方案的适用边界
4. 第二阶段：架构腐化的防控与治理
   • 现状与缺口：ADD 已在资产中定义了结构约束（依赖方向、数据所有权、不变量），缺少的是合规性校验与架构健康度的度量反馈闭环
   • AI 引发架构腐化的五大风险：局部样例模仿导致风格异化、加法偏好引发冗余膨胀、设计意图未纳入上下文、变更吞吐与审查节奏不匹配、验证逻辑迎合当前验收标准
   • 四维治理视角+一横切维度：代码质量、端点与契约、数据资产、技术组件，叠加设计意图与系统现状的偏离度可追溯
   • 落地执行路径：从架构主张到仓库适用规则，再到可落地的检查证据；特殊场景采用例外登记而非放宽规则；存量系统问题先分类治理，增量变更严格执行门禁管控
   • 机械信号与模型判断的边界：代码克隆不等同于知识重复，规则声明不代表实际运行生效
5. 第三阶段：迈向「需求输入、代码输出」的端到端交付
   • 现状复盘：编码环节已相对成熟，自测环节是当前体系最薄弱的一环，过程合规不代表质量达标
   • 资产驱动测试：业务规则、不变量、接口契约本身就是天然的测试断言来源，将其转化为可执行测试，才能为自修复循环提供输入
   • 流程升级：从「给模型读取的散文式流程」转向「可被程序执行的流程图式流程」，实现流程定义与执行分离、状态可落盘、循环逻辑显式化
   • 端到端交付的边界与验收标准：明确人工必须参与的环节，以及可完全自动化的环节
6. 落地实践：效果、踩坑与未来方向
   • MVP 落地节奏：1 周完成框架初始化、3 周完成核心端点梳理、第 5 周正式切换运行
   • 常见认知误区澄清：ADD 等同于写文档吗、AI 能力足够强就不需要约束吗、先写代码再补资产是否可行
   • 实践踩坑总结：规范写成散文式文本导致模型理解偏差、校验重流程轻产出、不同 Skill 执行口径不统一

听众收益

• 了解一套可直接复用的存量系统 AI Coding 治理框架：明确资产分层方式、Skill 定义方法、人工确认节点设置原则
• 了解一把 AI Coding 流水线成熟度评估标尺：清晰编码前、编码中、自评审、自测、合并门禁各阶段的能力水位
• 学习架构度量的落地起步方法：先明确架构主张再制定度量指标，避免度量沦为纸面报表

Coding Agent 正在提升代码生成效率，但当它进入团队级交付流程，新的工程问题随之出现：执行步骤不一致，实现与评审缺乏有效隔离，验证能力难以跟上并发增长，失败后也缺少清晰的恢复路径。单次任务的成功，并不等于团队获得了可持续的软件交付能力。我们的实践表明，除模型能力外，流程约束、验证机制与人机职责划分同样决定交付结果。

为此，团队构建了多 Agent 交付平台 LoopForge：以确定性 DAG 定义流程主干、节点依赖和门禁，以 Agent 完成节点内的分析与执行，并在关键决策点保留人工审批。通过可执行 SOP、实现与评审角色隔离、交付产物留存及失败重跑，将依赖单次会话表现的执行过程，转化为可验证、可追溯、可恢复的交付流程。

本次分享围绕三个递进的工程问题展开：如何让单个需求按既定流程完成交付；如何在任务并发增长后，通过分层质量门禁控制变更风险；如何将交付流程延伸至生产运维，形成“巡检发现—聚类建单—自动修复—验证—人工确认合入”的闭环。团队基于该体系累计合入 836 个合并请求（MR），日均吞吐提升7.8倍，无线上故障；在 SkillHub 场景中，最近一个月完成自动修复0人工干预并合入的线上 Issue 超过 60 个。分享会讲清每个阶段的落地成果、推进路径和踩过的坑。

演讲提纲

1. 交付困境：Agent 能写代码，为什么交付不稳
   • 四个症状：流程不可复现、自己评审自己、关键关口无人把控、过程不可追溯
   • 一个误区：以为让 Agent 自由编排就够了，实际在批量执行时会跳步、跑偏、中途停下
2. 核心思路：DAG 管主干，Agent 管节点，人管签字
   • 职责边界：流程、门禁和回退交给确定性编排，执行细节交给 Agent，最终判断交给人
   • 演进总览：从 Human in the Loop（人盯过程）走到 Human on the Loop（工程托底，人只做确认）
3. 阶段一 稳定交付：把团队经验变成可执行的 SOP
   • 四类节点：Agent、脚本、人工审批、子 SOP；不需要 AI 的地方就不用 AI
   • 角色隔离：实现、评审、测试使用独立的上下文和模型，避免自己评审自己
   • 可回溯：节点之间通过产物交接，在途任务锁定 SOP 版本，失败后可以从指定节点重跑
   • 效果：累计交付 200+ 个需求与 Issue，产品和后端同学跨界合入 105+ 个前端 MR
4. 阶段二 规模化质量：用验证门禁替代人盯
   • 新瓶颈：一个人能同时并发十几个任务，再靠人逐个盯，质量和吞吐无法兼得
   • 5 道门禁：单测与增量覆盖、Diff 缺陷挖掘、异构模型交叉审查、3 分钟分支环境加 E2E、产品体验走查
   • 效果：合入 836 个 MR，无线上故障；一次通过率 54.8%，经过门禁打回和 Agent 返工后，终态成功率达到 95.4%
   • 踩坑：一次通过率低的根源在上游需求质量，前置需求澄清门禁比加并发更有效
5. 阶段三 主动闭环：从人提需求到系统发现问题
   • 新瓶颈：交付已经稳定，但问题仍然要靠人发现、建单
   • 闭环链路：日志、K8s、慢 SQL 巡检 → 聚类建单 → 缺陷修复 SOP → MR、测试报告和根因报告 → 人工确认合入
   • 效果：最近一个月自动修复并合入 60+ 个线上 Issue

听众收益

• 掌握一套多 Agent 交付流程的设计方法。能够划分确定性编排、Agent 自主执行和人工审批的职责，理解节点类型、角色隔离、产物交接与失败恢复的设计要点
• 获得一份分层质量验证的参考清单。理解单测、变更审查、异构模型审查、分支环境 E2E 与产品体验走查各自承担的验证职责，以及验证失败后如何反馈到修复流程
• 建立一组评估交付体系的指标视角。使用一次通过率、终态成功率、执行耗时、端到端耗时和项目实际使用情况，识别问题主要出在需求与上下文、验证机制，还是人工协作环节

AI Coding 提升了个人编码效率，但需求澄清、方案评审、环境准备、测试与发布仍依赖多人串联，组织交付效率未必同步提升。本次分享基于字节内部研发实践，以 AgentKit 为案例，介绍如何以 Spec 明确目标、边界与验收标准，将人工决策与多 Agent 执行编排到同一交付流程。重点剖析 AgentKit 支撑的身份权限、沙箱运行、Skills/MCP、质量门禁及观测评测机制，并通过需求澄清到验收回写的全链路演示，说明任务如何委托、结果如何验收、异常如何转交人工。最后给出以交付周期、一次通过率、人工介入率和缺陷为依据，逐步提升自治等级的落地方法。

演讲提纲

1. 效率鸿沟：为什么个人提效没有自然转化为组织提效
   • 分析 AI Coding 提升编码效率后，需求澄清、方案评审、环境准备、测试与发布中的协作瓶颈，明确从代码生成走向端到端交付需要解决的问题
2. Spec 驱动：建立人和 Agent 的共同任务合约
   • 通过 Spec 明确目标、边界、依赖与验收标准，结合项目上下文统一理解
   • 定义流程节点的输入、输出、证据与责任，减少执行偏差
3. 多 Agent 协作：基于 AgentKit 构建可控的研发流程
   • 人工决策与 Agent 执行编排到同一流程
   • 介绍 AgentKit 的身份权限、沙箱运行、Skills/MCP、观测与评测能力
   • 介绍质量门禁和人工接管机制
4. 全链路实践：从需求澄清到验收回写
   • 演示需求澄清、Spec 确认、Agent 编码与测试、环境部署、验收及结果回写的完整链路，说明关键决策点与异常处理方式
5. 渐进式落地：从场景试点到团队推广
   • 选择边界清晰、验收明确的高频场景，以交付周期、一次通过率、人工介入率和缺陷衡量效果，逐步沉淀流程模板、知识与失败经验

听众收益

• 获得一套 Spec 与流程节点设计方法，能够把模糊需求拆解为有明确输入、输出、责任与验收证据的 Agent 任务
• 理解多 Agent 交付所需的关键工程能力，以及权限、沙箱、质量门禁、观测评测和人工接管的设计要点
• 获得从小场景试点到团队推广的实施框架，能够通过交付周期、一次通过率、人工介入率与缺陷等指标评估实际收益