腾讯陈偲颖AICon演讲：AI原生研发工具链如何重构

当 Agent 真正进入企业流程，哪些工作能放心交给 AI？50 + 实战案例将给出答案。

AI 的定位正在改变。它不再只是回答问题、充当辅助工具，而是开始理解目标、调用系统、把任务做完。Agent 进入企业流程后，摆在面前的问题换了：不是“怎么把 AI 做出来”，而是哪些活能交给它、产出怎么验收、权限、成本与风险怎么管住。大模型朝推理、工具调用、多模态和长任务方向延伸，开发重心也从单次调用转到上下文、工具、执行环境与反馈回路的设计上。Coding Agent 同样在变，从代码补全走到能读懂代码库、跑测试、完成复杂任务的工程协作者。OpenAI、Google Cloud、Anthropic 的最新实践指向同一个结论：模型决定 Agent 能做什么，工程决定它能不能真正进生产、创造价值。

2026 年 AICon 人工智能开发与应用大会 · 北京站已经启动，时间定在 12 月 18–19 日，地点是北京新云南皇冠假日酒店。大会主题为探索 A 应用边界，共设 13 大技术专题，方向包括大模型后训练、推理优化、Agent 工程、知识工程、智能体评测与安全、自进化系统、AI 软件交付、原生架构及组织变革等。届时一线技术专家将到场，分享 AI 技术突破与企业规模化落地的真实实践。

腾讯资深研发工程师陈偲颖已确认参加“Agentic Software Engineering｜从代码生成到软件交付”专题，带来《AI Native 企业研发工具链：架构重构与持续演进》主题分享。Agent 参与企业业务研发后，要承担需求拆解、业务配置与实现、质量校验等任务，工具链面对的问题随之改变：单次业务系统操作成功，怎么保证整条研发任务链路正确？长任务里出现业务状态偏差和上下文失真，怎么发现、怎么恢复？业务操作权限怎样随风险受控开放？一次任务中的修正，又怎么变成下一次可复用的经验？这些问题牵涉业务系统接口、Agent 运行时和治理机制，需要在平台层统一处理。

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

架构定位是“AI 的操作系统”，核心目标是压减任务执行中的不确定性。输入侧靠知识、规则和上下文把方案收敛；输出侧让用户看懂执行过程、判断结果是否可信，并且能直接修改。权限、审计、评测和人工审批贯穿全程，Agent 得以在受控范围内逐步接手更多工作。

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

陈偲颖是腾讯资深研发工程师，曾在多家全球知名科技公司任职，专注营销活动技术领域，持有多项技术专利。2023 年起，她把重心放到 LLM 与工程效能的深度融合上，作为核心负责人主导某互联网大厂低代码平台的 AI 能力建设；多年数据资产的价值转化也已完成，把人工经验沉淀提炼为知识复利方法论，构建起“LLM + 低代码”双驱动的智能研发体系。她还打通了“一句话需求到上线”的端到端智能化链路，推动承载数百款业务的平台从传统开发模式向 AI 原生开发范式演进升级。

她在本次会议的详细演讲内容如下：

演讲提纲

1. 问题：从完成一次任务，到稳定支撑研发流程

• 单次业务系统操作成功，不等于研发任务完成。跨系统执行时，业务约束与结果一致性都需要校验。

• 长任务中一旦上下文失真、状态出现偏差、失败重试，局部错误就会被放大。

• 不同 Agent 的权限、审批与恢复机制如何统一管理，才能让跨系统任务始终处在受控范围？

• 单次任务中的用户修正，怎样转化为可复用的经验，让同类错误少发生？

2. 架构：以“AI 的操作系统”为定位，围绕任务降熵建设底座

• 业务操作工具协议化与能力原子化

• 用统一工具协议封装企业业务系统的操作能力，按业务语义划边界，让能力保持正交，同时明确重试与幂等约束。一个工具，对应一项说得清楚、结果可校验的业务操作。

• 工具描述采用“动作 / 输入 / 输出 / 用例”四段式，写明业务对象、操作前置条件、影响范围与结果状态，副作用要显式声明。

• 业务操作的粒度不能一味拆细：拆得过粗，业务判断和变更范围会被藏起来；拆得过细，跨系统调用、上下文负担和中间失败点又会增多。

• Agent 运行时工程化与低代码 Harness

• 业务操作工具召回、Prompt 组装、任务状态机、Hooks、执行观测与回放，统一由 Harness 承接，每个业务场景不必重复搭执行逻辑。

• 任务执行与扩展点配置用低代码方式组织，业务团队组合能力、接入 Agent 的成本随之降低。

• 低代码流程与代码实现被打通，业务侧要的易用性和研发侧要的灵活性都能兼顾。

• 取舍也要讨论：哪些能力由平台统一约束，哪些留给业务扩展；低代码覆盖到哪一步，什么时候该进入代码层。

• 先看输入侧。上下文工程要走平台化，目的就是让进来的信息少些歧义。

• 专家知识库在这里承担业务依据的角色，给意图理解和方案生成提供支撑；规则则可以按业务、渠道、场景分别配置，在任务的各个环节里引导执行。

• 上下文管理把信噪比放在第一位：围绕当前任务来组织业务规则、配置和系统状态，再用分层缓存、结构化切分和上下文预算管理把信息规模压住。

• 当前任务状态、业务规则和个人记忆要分开对待，否则过时的业务配置或者个人偏好容易被误当成当前系统的事实。

• 治理不是一次性动作，它贯穿执行的整个过程。

• 权限控制、审计和评测都放进运行时里，再根据任务风险和验证结果，一点点放大自动执行的范围。

• 在授权范围之内，低风险、可恢复的操作可以交给系统自动做；高风险或者不可逆的变更，则要人来确认。

• 自动执行和人工介入之间的边界由 Harness 统一管理，关键步骤上通过 Hooks 触发校验或者人工确认。

3. 评测与人机分工：让用户看得懂、信得过、改得动

• 看得懂，指的是把业务方案、目标系统、流程节点和关键配置摆出来，用户能知道系统准备执行哪些操作。

• 信得过，指的是业务约束、校验结果和执行记录都查得到。场景化 Eval Set 由团队自建，方案与结果用 LLM-as-Judge 评估；确定性约束还是交给程序校验。

• 改得动，指的是业务配置、流程节点以及必要的代码用户都能调整，不必因为一处局部错误就把整个任务重跑一遍。

4. 摩擦驱动自进化：把失败与修正变成可复用的经验

• 高价值信号往往出在任务跑不顺的地方：用户打断、业务操作连续失败、任务卡死，还有用户对方案和配置的修改。

• 闭环是这样走的：先明确数据使用范围与留存边界，在此基础上采集必要的执行记录与反馈 → 串联任务过程 → 判断问题来源 → 提炼规则 → 评测验证 → 写回 Harness，按风险灰度生效。

• 共性的执行问题归 Harness 统一处理，业务之间的差异靠规则和 Skill 扩展，验证过的经验再沉淀成可复用的能力。

• 知识复利说的是：经过验证的经验可以跨任务、跨团队复用，让后续执行持续变好。

5. 下一步：把平台经验沉淀成研发协议族

• 协议沉淀：业务操作工具协议、上下文协议、Harness 扩展点协议和审计协议，一并沉淀为内部研发 AI 协议族，供跨团队复用。

• 知识沉淀：从研发任务的操作记录与反馈里提炼验证过的规则、模板和案例，做成可复用的内部知识资产。

• 开放共建：协议与治理留在平台，能力怎么组合交给一线业务团队；不同场景由低代码 Harness 和可配置规则来承接。

• 验证的是端到端提效、接入成本和复用效果。

听众收益

• 了解企业研发 Agent 底座的设计思路，掌握业务操作工具拆分、低代码 Harness 编排与上下文管理的关键取舍

• 学习 Agent 任务的质量校验与人机分工方法，通过权限、评测和人工审批，让执行过程可检查、结果可修改

• 学会从执行出错和用户纠正中提炼经验，把规则沉淀下来，经过评测验证再灰度上线，同类任务的重复错误就能少一些。

想了解更多，可以扫码，或者联系票务经理 18514549229 咨询。