CGL 集团，中国领先的高管寻猎与领导力咨询集团
9 月 23 日下午，2026 云栖大会「AI 原生研发组织论坛」在杭州国际博览中心一期一楼 103B 厅举行，从 13:30 持续到 16:45。官方在会前的剧透里，先把整场论坛的判断给了出来：
Agent 是否真正进入生产链路、承担真实工作，并重新定义组织的流程、角色、协作与度量方式，是研发组织能否迈向 AI Native 的重要分水岭。
这句话里最重的词不是「Agent」，是「分水岭」。
因为「用上 Agent」和「Agent 在生产链路里承担真实工作」是两件完全不同的事。中间隔着的也不是技术选型，而是流程、角色、协作与度量这四件组织的事——它们恰好都不在研发工具的解决范围之内。
先把这场论坛的位置交代清楚。2026 云栖大会 9 月 22 日至 24 日在杭州国际博览中心举行，主题「智以致用」，设 3 大主论坛共 4 场、120 余场分论坛、4 大主题展馆，超 5 万平方米展区。AI 原生研发组织论坛是 9 月 23 日下午的一场分论坛，由阿里云 CTO 线承办，形式是七个专题分享加一场圆桌，覆盖产品设计、代码审查、代码修复、研发协作、全域运维、组织进化与产品运营七个环节。
| 1 条分水岭 | 7 个环节 | 4 件事被重新定义 |
|---|---|---|
| 官方给研发组织 AI Native 的判据 | 从产品设计到产品运营的完整链路 | 流程、角色、协作与度量方式 |
三项均引自论坛官方剧透，来源为阿里云开发者社区，发布时间 2026 年 9 月 20 日。
一、官方把分水岭画在了生产链路这一格
七个专题的名字里都带着「进化」，但它们不是同一件事的七个侧面——它们是同一条链路上的七个卡点。
官方对其中两个环节的描述，本身就把问题说清了：
AI Coding 提升了写代码的速度，却未必同步提升团队的整体交付效率。
AI 生成代码让 PR 数量快速增长，代码审查的瓶颈也从有没有工具转向是否真正懂业务。
前一句讲研发协作，后一句讲代码审查。两句话指向同一个现象：提效先发生在个体手里，再往后就卡住了。
组织进化那一节的官方表述更直接：
产品内置 Agent，并不意味着研发组织已经实现 AI Native。
论坛给出的答案是一条完整路径：真实问题经过样本沉淀、评测定位、Agent 修改、多级验证和人工放行，转化为下一版产品能力；而当产品开始受控自进化，研发、安全、测试与交付团队要围绕结果重构协作。
注意最后一个动作的主语——不是研发团队，是研发、安全、测试与交付四支队伍。 这就是「分水岭」在组织结构上的真实位置：它不落在某个工具的上线日，落在多支队伍的协作方式被重写的那一天。
同一场论坛里，全域运维那一节把前提讲得更朴素：Agent 要进生产环境，首先需要一把可信的尺子。官方给出的做法是把真实故障演练、因果证据、可执行的真值标注与多重质量门禁连成一条评测数据生产线，为 Agent 的能力迭代提供可重放、可验证的评测基准。
这句话值得单独记下来。 它说的是：Agent 能不能进生产，取决于组织有没有能力给它出一个可信的分数。而「给分数」这件事，从来是管理问题，不是工程问题。
二、个人产能与全局吞吐之间，隔着一条协作链路
圆桌的官方命题比正文更锋利：
当个人产能不等于全局吞吐、工程师从写代码转向定位问题和全局兜底，组织与管理应如何升级？
「个人产能不等于全局吞吐」这一句，把过去两年企业 AI 投入最常见的落差一次说清了。
个人产能是分子，全局吞吐是分母。分子这两年涨得很快——代码生成、测试用例生成、文档生成，每一项都在涨。但分母里装的不是写代码的速度，而是需求等待、评审排队、跨团队对齐、返工与发布。分子涨了，分母没动，交付周期自然不动。
这也是我们服务企业一号位时反复遇到的那个问题：招的人更强了、个体产能更高了，为什么公司整体吞吐没上去。 到目前为止，最常见的原因不是工具不够好，是协作链路没有被重新画过。
圆桌还留了两个问题：AI 原生研发组织的北极星目标是什么，AI 原生度如何连接价值创造与商业成功；面对变革，个人与组织谁先行动。
| 被 Agent 接走的部分 | 留在人这一侧的部分 | 随之变化的能力 |
|---|---|---|
| 代码初稿、测试用例、文档与注释 | 定位问题、判断优先级、异常兜底 | 从写得快转向判断准 |
| 通用规则的静态检查 | 领域知识、缺陷模式、历史反馈 | 从执行规则转向沉淀判断 |
| 流程内的重复动作 | 目标设定、关键判断与最终决策 | 从做动作转向定方向 |
前两行依据论坛对研发协作、代码审查环节的官方描述整理，第三行依据产品设计环节的官方描述整理；「随之变化的能力」一列为我方归纳。
三、工程师从写代码转向定位问题，岗位画像就变了
「工程师从写代码转向定位问题和全局兜底」，是圆桌命题里唯一直接谈人的半句话。
它改的是岗位定义。写代码是一项可以被度量的产出，定位问题不是——问题的难度、影响面，以及「本来会出而最终没有出」的那部分，都很难在绩效表上找到对应格子。当岗位重心从「产出物」移到「定位问题与全局兜底」，招聘与评估的尺子就必须跟着换。
产品设计环节的官方表述把这件事讲得更完整：当 Agent 进入产品设计，变化不只是多了一个提效工具，更在于从需求洞察、方案构思到设计验证与迭代优化，开始由人与 Agent 共同完成。而人在这个新协作方式里的位置，被官方点明为三件事——目标设定、关键判断与最终决策。
这三件事听起来耳熟。我们在 2024 年 4 月 22 日的公众号文章[《AI驱动创新，重塑猎头行业未来——CGL的探索和实践》](https://mp.weixin.qq.com/s/gFUVK2L-M2B2rjnRnTdBbw)里，把行业与 AI 的融合划成了三个阶段——Embedding、Copilot、Agent。 其中给「Agent 模式」下的定义是：人类设定目标，AI 代理识别意图并规划实现步骤，自主完成任务。
当时那篇记录里还有几个读数：内部研发的 Sourcing Agent 经过两个月试运营，自动推荐了约 2000 名与顾问搜寻职位相匹配的人才，其中 76.3% 得到顾问认可并被推荐给客户进入面试；对 30 位顾问的跟踪分析显示，AI 推荐的候选人与职位的匹配度为 94%；业务流程标准化与操作 AI 化两个阶段叠加后，顾问整体人效提升 7.2 倍。
两年后回看，这几个数字和这场论坛讲的是同一件事：Agent 要交付的从来不只是效率，还有可被验收的稳定性。 而「设定目标、关键判断、最终决策」被留在人这一侧，不是因为技术暂时做不到，它本身就是分工设计的结果。
四、度量口径必须换，从产出量换成任务完成
把七个环节连起来读，会看到一条共同的迁移方向——度量对象正在从「动作」变成「结果」。
| 维度 | 换之前 | 换之后 |
|---|---|---|
| 度量对象 | 做了多少动作 | 任务有没有完成 |
| 交付口径 | 单点环节提效 | 端到端交付能力 |
| 质量判断 | 规则命中与否 | 是否懂业务、能否兜底 |
| 组织单位 | 个人与单一团队 | 研发、安全、测试、交付协同 |
依据论坛官方对各环节的描述归纳，为我方口径，不是论坛原句。
度量口径的更换有个特点：它不能等 Agent 全面铺开之后再换。 技术侧的上线是分阶段的，组织侧的调整如果滞后，中间会同时存在两套账——一套按动作量算，一套按结果算，而那段时间恰好是争议最集中的时候。
这也是我们对企业的一贯建议：先定层级，再定引擎。 口径属于层级问题，工具属于引擎问题；顺序反过来，工具上得越快，账越难算。
总结：分水岭不在工具侧，在承接侧
把这场论坛放回云栖大会的整体议程里看，它和前一天的技术主论坛讲的是一件事的两端。技术侧交出的答案是基础设施——让 Agent 可靠、安全、可审计、成本可控；这一场给出的是组织的问题清单。而清单上的每一条都指向同一件事：谁负责承接。
研发组织是这个承接问题最敏感的样本，因为它离技术最近、提效最先发生、协作链路也最密。但问题本身不限于研发。任何一支已经有 Agent 在干活、却还没有重画协作链路的团队，都站在同一条分水岭前。
启示：三个视角各自要判断的事
| 视角 | 要判断的事 | 判断的时间点 |
|---|---|---|
| 一号位 | Agent 的收益按个人提效算，还是按端到端交付算 | 在扩大投入之前 |
| CHRO | 岗位定义与度量口径要不要先换 | 在 Agent 铺开之前 |
| 董事会 | 组织的承接能力是否构成兑现风险 | 在预算批复之前 |
给一号位。 个人产能的增量会被协作链路吃掉，这不是工具的问题。判断这件事只需要问一句：我们最近一次因为 Agent 而上线的能力，有没有改变任何一条跨团队的流程。 如果答案是没有，那么这笔投入买到的是分子，不是分母。
给 CHRO。 岗位画像的变化已经开始，而且是从最难度量的那一端开始——定位问题与全局兜底。这两件事必须先有定义，才谈得上评估；定义与评估一旦滞后，招聘标准就会继续按「产出物」招人，招进来的人与岗位实际需要的能力之间会出现错位。
给董事会。 承接能力是 AI 投入兑现路径上最难外包的变量，也不是加预算就能买到的变量。它对应的都是很具体的问题：关键岗位有没有人、岗位定义有没有更新、度量口径有没有跟上、跨团队流程有没有因此被重画过。
关于事实与口径
关注 CGL，获取高管人才市场洞察与领导力前沿实践。
官网：global.wearecgl.com
