AI 正在重写软件研发流程，也把研发组织推到了变化的前沿。因此，"AI 原生组织"一词变得很热，但热度并不是我们此刻开口的理由。
阿里云 CTO 产研线围绕业务北极星目标展开的实践已经取得了一些局部成果，也开始暴露出更难的问题：当 AI 原生实践走入深水区，单点提效和局部最优远远不够。因为研发团队从来不是一个孤立系统，它嵌在业务、组织与产业协作之中。我们决定不等答案成熟，在探索仍在进行时公开分享真实的进展、困惑与未解之题。希望与更多研发组织相互验证、彼此激发，一起把"AI 原生研发组织"从一个"吸睛概念"，形成新的组织范式。
本文对云栖大会《AI 原生研发组织论坛》做一个简单的回顾，对一些精彩的观点和有用的实践，做一个总结。由于篇幅关系，本文从组织纬度进行回顾，另有7个落地实践将分别由7篇独立的文章展开。
一个大型研发组织在 AI 原生实践中的阶段性观察
阿里云研发副总裁唐洪回顾了近几年的技术变化。 唐洪先从技术变化的速度讲起。他按时间线回顾：2022 年底，ChatGPT 让大家看到，通用的预训练模型可以解决很多问题，不需要每个领域都做一个细分模型；推理模型出现后，模型不只可以对话，也开始长思考、帮人解决问题；再到工具和记忆被接入，Agent 开始直接干活，包括接收目标、制定计划、执行任务、读取工具反馈，再根据结果修正和迭代。
他把今天的智能体计算范式概括为"模型加 Harness 加 Context"：模型负责理解、判断和实时决策，Context 提供全面、统一、持续更新的上下文，Harness 负责智能体的自主运行与持续进化。当这一范式逐渐清晰，模型能力继续提高、算力逐渐变便宜，Agent 会一步步进入生产的各个环节。问题也随之变成：怎样用好 Agent 的能力，把潜在的生产力变为现实。
过去三个月，阿里云 CTO 线启动了一轮面向研发组织的 AI Native 探索。唐洪强调这轮探索不是为了解决某一个具体的技术难题，也不是为了创造某一个产品，而是针对组织本身，思考怎样用 AI 解决组织问题和协同问题，并创造实际价值。
基于这轮探索，他提出了三个判断。第一，Agent 进入生产链路，才是真正的分水岭。第二，AI Native 不单单是为了降本，"降本是第一位"，更重要的是竞争维度的跃迁。第三，AI Native 会经历三个阶段：先是工具原生，让个人用好 Agent 工具；再是工作流原生，让原本需要很多步骤完成的事情尽量由 Agent 贯通；长期目标是组织原生，让整个组织以 AI Native 的方式工作。唐洪也强调，技术发展得很快，他们自己仍在探索，不敢说这次论坛提供的是标准答案，更希望借这个场合相互切磋、相互印证，抛砖引玉。
阿里云 CTO 线组织发展负责人蔡亮从组织视角解释了这轮探索的出发点。 他提到早期的打字车间和数据打孔车间：每个时期的组织和管理都在回应当时的技术条件和能力供给。在他看来，技术变化会改变能力的稀缺程度，组织分工也必然随之调整。
在他看来，AI 没有让个体能力、协作和管理的稀缺性完全消失，同时增加了一个过去没有的边界：人类第一次要和非人智能体共同工作。当 Agent 开始承担任务，新的契约怎么建立，目前还没有现成答案，会经历一个持续的探索和建设的过程。
这轮探索把问题分成两类。一类是"成长型"问题：在现有框架内极致优化，继续检查需求、产品、设计、开发、测试、发布和运维整条链路，寻找任何可以提升的空间。另一类是"进化"问题：在 AI 能力和客户价值之间，颠覆和重构一切。
这轮探索采用"北极星、留白、沙箱"的推进方式。"北极星"目标至关重要，起到动员和激发 AI 原生转型创新的作用，同时也决定了哪些创新需要持续加注；留白意味着创新不用等待管理配套完全准备好，允许团队在试验阶段跨越原有岗位边界；沙箱为尝试提供支持环境，并尽量控制对主干生产链路的影响。观测过程指标用于观测和比较，不直接进入考核，用"发现"新物种的模式，目的是减少针对指标过度局部优化的动作变形。
样板间的入选标准包括进入生产场景、有可观测的业务结果，并具备复用可能。
经过几个月的尝试，出现了一些局部的成绩，例如某个项目将全链路处理时长从 两个小时缩短至 5 分钟；另一个项目在两周内完成 几十个需求，将发布周期从 40 天缩短到 2天，并整理出十几个生产级的 Skill。这些数据不代表整体表现；样板间实践中哪些做法可以复用，仍需继续验证。阶段性实践带来了两方面变化：一是核心资产开始重构，从产物本身转向支撑可信再生的条件；二是下一阶段的平台级需求逐步收敛到三个方向。
- 第一，让任务可靠执行。围绕 Harness 和"规范即代码"，补齐执行约束与运行治理、多 Agent 编排、自动验证与验收，并用硬标准设置验收门槛。
- 第二，让经验持续积累。推动工具、Skill 和 MCP 资产化，把经验提炼、评测和版本演进连成闭环，并继续探索能力的自进化。
- 第三，让协作进入组织。围绕多 Agent 编排和"Agent 进组织"，继续处理角色升维与团队混编、Agent 身份权限、Human + Agent 协作、端到端可观测与效能分析，以及 Agent 场景的理性选型。
Panel：人和 AI 之间的新契约
Panel 由阿里云智能集团 CTO 线组织发展负责人蔡亮主持。三位嘉宾分别是：阿里云智能集团副总裁、CTO 办公室负责人唐洪，阿里云智能集团副总裁、公共云业务事业部解决方案总经理韩鸿源，以及蚂蚁百灵产品和运营负责人、AAIF 大使边思康。
本次论坛少见地把圆桌讨论设置在7个实践议题之前，目的是补充论坛上下文，让参会观众更有代入感。
从个人实践谈起
蔡亮： 第一个问题先给洪哥。你是一个 AI Native 实践者，也是六千多人研发组织的管理层。你自己是怎么做 AI Native 实践的？对你到底有什么帮助和价值？
唐洪： 先声明一下，我们试图预演过，但每次都像模型输出一样，非常不稳定，所以这次决定即兴。这个问题，我之前也没听过。我从初中开始用计算机写代码，后来经历了 PC、互联网、移动互联网和云计算时代。今天我很深的一个感受是，写代码的热情又回到了初中、大学毕业和刚从业的时候。
一个新的技术时代到来，第一件事还是保持谦虚，真正去学习它。技术看起来是螺旋上升，每一轮都能看到过去的影子，但每一次上升又有质的变化。如果问什么是 AI Native，我觉得自己必须先用它，先尝试改变我处理问题的方式，再去改变周围同学解决问题的方式。只有真正进入这些问题，才会知道它到底是什么。
蔡亮： 洪哥先"跳下去"了。老韩，你也讲讲你自己。
韩鸿源： 我可能是在座唯一一个不写代码的人。我从来没有把写代码当成全职工作，但我是把代码生产出来的东西，最终拿给客户的人。
跟代码有关的词至少有三个：Coding、Programming、Software Development。它们最终可能都落到 Coding，但差异很大。代码写出来，并不等于有了 Software，最多可能只是一个能运行的 program。
真正的软件有大量功能性和非功能性要求。现在很多工具叫 Coding Agent，因为 Coding 是工作量的实现过程；但 Software 里还有太多事情，Coding 不能直接解决。能不能把一段代码变成真正可交付、可售卖、可持续运行的软件，这里面还有很大的讨论空间。
蔡亮： 洪哥说要自己先跳下去；老韩追问的是，你到底是在砌砖，还是在修教堂。思康，你呢。
边思康： 砌砖，可以修教堂，也可以盖集市。
今年有一种针对程序员的焦虑：一些以前不写软件、也不懂软件的人忽然跑过来说，你们创造的 code 没有价值了。但 code 在整个软件服务中，本来就只占一部分，更像原材料。你要把 code 做成好的软件，再把软件做成好的服务，还有很长的产业链。
所以我仍然长期看好 SaaS。客户的具体需求不会因为代码变便宜就消失。老韩见过的客户，我没有见过，我不能因此就说自己懂那个客户，那会很傲慢。真正可能发生变化的是 software 的交付方式。
我很喜欢一个说法：SaaS 还是 SaaS------也可以理解为"Service as Software"。coding 的成本下降了，其他准出要求、评测要求反而可能提高。原材料看起来一样，但架构、装修以及整条产业链都会变化，对专业能力的需求不会降低。
代码变便宜以后，什么仍然稀缺？
蔡亮： 刚才讲到砌石头还是修教堂。但教堂也分很多类：阿里云做 PaaS、内核、基础软件，其他团队可能做应用软件。不同类型的研发组织，受到 AI 冲击的方式会不会不同？老韩先来。
韩鸿源： 上一个被 native 修饰的词是 cloud native。当年虽然也争论了很久，但至少还有 Twelve-Factor 这类判断因素。今天说 AI Native，好像还没有找到类似准则。
如果一定要给一个方向，我认为是：组织里可以让 AI 做的事都让 AI 去做，但做完以后，北极星指标不能下降。
软件和程序的区别，很大程度上来自运行、检验和重复验证。需求和测试从来覆盖不了生产环境里的全部问题，AI 今天也未必能做到。所以某些程序可以"日抛"，但我不相信真正的软件会日抛。软件必须经历从设计、生产到检验的完整生命周期，还要经过足够多的真实运行，才可能成熟。
尤其是底层基础设施软件，它的非功能要求、架构治理和持续演进能力，远比把代码写出来更重要。这些东西仍然需要长期锤炼。
蔡亮： 如果原来开发软件的大部分成本来自开发团队，现在代码生成越来越便宜，在阿里云 CTO 线，你觉得能力稀缺性和能力要求发生变化了吗？
唐洪： 当然变了。代码生成越来越便宜，反而暴露了其他问题。
传统瀑布式软件流程，默认人力成本最贵，所以要尽量避免返工，要做一遍遍的设计评审、规格评审。现在软件迭代越来越快，如果流程还很重，前面的环节就会变成新的瓶颈。
原来很多事情靠组织分工、靠人把关，再通过人来 handoff。但人的 handoff 通常比机器慢。产品经理开始干研发的活，研发也开始干产品的活，是因为只要是两个不同实体，观点就可能不同，协调就有代价。
举一个真实例子：过去前端库和后端库分开，后端先上一个版本，前端理解语义后再接。变化慢的时候没有问题。今天两边都在快速迭代，后端往前走了很多，前端可能根本接不上。那最好的方式，反而可能是把代码放在同一个库里一起改。
再往后，software 是什么也可能需要重新定义。从打孔卡、汇编语言到高级语言，软件一直在充当人的意图与机器执行之间的桥梁。未来也许会有一种比自然语言更可靠、又不同于传统程序语言的表达，让 Agent 更准确地完成任务。
所以软件的定义、软件工程，以及人在其中的角色，都可能发生全面变化。今天很多问题没有答案，但我是比较乐观的：有问题才有机会。
蔡亮： 我们做的不是代码，要的是软件；要的也不只是软件，而是服务，甚至是客户的微笑。
边思康： 每次技术周期开始，都会有东西重组。大数据出现以前，没有今天意义上的数据分析师、Data Scientist。这些新岗位来自新技术，但它们要解决的问题没有本质变化：客户仍然需要知道，怎样更好地经营业务，怎样处理供给和需求。
不能因为机会来了，就飘到觉得用 Vibe Coding 能直接造一个企业级系统。好的性能工程师、安全工程师，仍然是多年训练形成的专业人士。未来工作负载会变，REST API 可能变成 Token，系统设计方式也会变，但结构、安全、性能这些专业问题并不会消失。
真正会变的是客户侧的交付，以及客户对新事物的想象。客户有时讲不清自己想要什么，需要有创造力的人先做出新的作品，让大家意识到"原来还可以这样"。年龄未必最重要，更重要的是保持开放，并且用科学方法不断发现新东西。
蔡亮： 今天反复说"专业的人做专业的事"，但专业边界似乎正在模糊。我们原来有技术委员会、专业域和岗位标准，可现在这些标准越来越难定义。客户需求在变，工具也在变，那么专业到底还值不值钱？又在什么地方发挥作用？
唐洪： 过去大家常问，哪些智能是 AI 能攻克的，哪些是人的专属能力。后来有人用海水和小岛作比喻：人的专家能力像岛，AI 能覆盖的范围像海平面。海平面不断上涨，露在外面的"专家小岛"就越来越少。
今天 AI 在产品设计、交互和复杂的非功能设计上还不够好，但能明显看到它在进步。有些原来很难的系统问题，也可以通过语言、工具和工程体系来共同解决。AI 不是凭空解决一切，但给它合适的工具，它就能进入更多专业领域。
这意味着专家不会简单消失，但专家的 bar 会越来越高。
不过我认为，人还有一个比较独特的地方：如果产品最终是给人用的，那么好不好用、舒不舒服，涉及 taste 和产品 sense。这可能是很难完全退掉的能力。
蔡亮： 这个结论，我们先"拭目以待"。按你刚才的逻辑，它也可能只是时间早晚的问题。
确定的软件与不确定的模型
蔡亮： 老韩，从客户角度看，大家现在是不是处在同一个阶段------虽然都说在探索，但实际进展完全不同？
韩鸿源： 有些变化的好处已经看到了。产品进入开发领域，开发进入产品领域，这种 overlap 有助于协作。过去软件研发里的很多阻碍，就是衔接不畅造成的；如果完全不进入对方领域，衔接不可能真正顺畅。
但还有另一个问题：模型正在快速变化，大家都说模型可能吃掉外围能力。软件过去最喜欢确定性，最怕不确定性；现在模型直接把不确定性引进了系统。
我一直有一个观点：如果你写了一个 AI 应用，而新一代模型发布后，这个应用完全用不上模型增强的能力，那你要反思自己是不是真的在用 AI。你的系统不应该把模型锁死在旧版本上。
但反过来，也不能因为写代码能力增强了，就直接推导出 AI 已经能从头到尾替代人。比如 MySQL 有完整文档、清晰接口，也有很多众所周知的问题。今天有没有人用 AI 重新写出一个更好的 MySQL，并真正替换掉它？还没有。
编译器可以一次运行结束，数据库却要持续运行。对于基础设施类软件，AI 能不能一次性写完并长期可靠运行，还没有经过充分验证。所以在这件事上，我偏保守。
蔡亮： 越被别人依赖，稳定性就越重要；而我们依赖下面的系统，上面的用户也依赖我们。
韩鸿源： 对。很多软件看上去的复杂性，远低于它实际的复杂性。
边思康： 我和老韩没有对过，但他说 MySQL 这件事，让我想到一次对话。我说 MySQL 是基础设施，我以前的 leader 说："打住，MySQL 不是基础设施，MySQL 是应用。"因为他做的是容器和操作系统。
这传达了一个信息：我们今天赖以为生的基础设施，在某个时代以前都不存在；它下面还有它自己的基础设施。所以我们现在可能处在非常草莽的阶段。
模型的状态本来就带着不稳定性。你给模型一个 prompt，它给出一个奇怪结果，有时那未必是 bug，而是它最底层的特征。它像一块并不规整的砖，甚至更像水泥。它会带来需要解决的问题，但对很多人来说，这也是重新发现、创造和构建的机会。
Harness 也是这样。简单问题被解决以后，下一阶段的问题就会需要更多测试，而测试本身要面对不确定性。
软件是确定的，但人类世界是不确定的。过去我们用软件把部分不确定性收敛成确定流程；现在用一个不确定的模型去应对客户的不确定需求，就要重新设计中间这一层。
我理解的"Service as Software"仍然成立：把确定的部分抽象成 Building Block，再把它和模型、Context 叠在一起，去应对客户不确定的需求。它可能更多是视角变化，而不是所有事情都被彻底推翻。工程师仍然有机会重新调整、重新适应，我不认为这只是一个"谁会被淘汰"的问题。
研发组织先改什么？
蔡亮： 最后问一个问题。如果要走向 AI Native，只能增加一种机制，或者移除一种机制，你们会选什么？
唐洪： 我没法完全顺着这个问题回答，因为组织里的机制环环相扣，只换一个 piece，它可能根本放不回整个 puzzle。
如果一定要说最重要的改变，我认为首先要相信它会到来。Everything could be broken, could be changed。所有规则都有可能变化，只是你不能把规则拆完以后，让整条路彻底断掉。你要找到一条演进路线：这里断一个，那里改一个，但至少还有一条路能走通。
比如今天软件边界必须定义得非常清楚：输入、输出、参数、版本、正向兼容、反向兼容。但到了 Agent 时代，有人在研究 API 能不能协商：我先问你能做什么，再搜索和选择，服务之间像人在对话。
并非所有软件都必须这样。抽象特别确定的地方，RPC、MySQL 也许就没有必要。但一旦不确定性上升，部分边界就可能变化。
所以，当你相信那个未来一定会发生，看到它和现有规则冲突时，要先审视现有规则是不是可以被打破。
蔡亮： 也就是保持开放。看到新事物和过去经验冲突时，别先做膝跳反射，证明它不应该发生。
韩鸿源： 我说两个事。第一，研发组织最需要改变的是打破职能边界。一定要有更多 overlap，AI 可以帮助你进入以前不属于职责范围的领域。重叠更多，沟通才能更顺畅。
第二，软件要经过足够多的运行和检验，成熟度必须从这里来。如果代码、接口和对外合约都不稳定，就没有办法重复检验；不能重复检验，每次运行都可能重新引入风险。很多非功能问题，只有进入生产环境、经过足够多客户环境的验证，才会暴露。
蔡亮： 听起来像两个相反的观点：一边要打破边界，另一边又要稳定合约。
韩鸿源： 开发过程中要打破人的职能边界；真正进入系统级运行时，合约只能逐步调整。你不可能今天端到端地写出一个 Windows，Windows 仍然需要分层构建。
蔡亮： 明白了。边界不应该继续绑在人身上，但边界转移到哪里、由什么承载，今天还来不及展开。
边思康：我不确定这算不算一种机制。如果问少做什么，我会说：少问一点"为什么这个东西还没有"，也少问一点"这是不是我的事情"。
乱纪元的特点就是，有些东西没有，就是没有。那你可以去写，可以去创造。组织边界长期演化，中间一定有过渡态。与其反复讨论这件事归不归我，不如先问：业务和客户的问题没有被解决，我能不能多做一点？
如果问要多做什么，我选"工具"。现在缺少新的工具，也缺少新的、带引号的"原子能力"。
Agent 写邮件，可能会调用 Gmail 或阿里邮箱，但通常不会重新用 IMAP 造一个邮件系统。一个好用的工具封装，可以近似看成一种原子能力。未来的中间件，可能就来自这些原子能力的重新构建。
现在这部分做得还太少。过去工程师不一定被鼓励做这种事情，因为看起来太小；但在今天，它反而可能更难、更重要，因为很多能力需要被重新抽象。
蔡亮：这个话题今天先悬停在这里。
七个样板间：生产场景中的做法与问题
论坛从产品设计、代码审查、代码修复、研发协作、运维评测、跨职能协作、产品运营7个维度，分别说明 Agent 在不同生产环节承担了什么工作、人仍负责什么，以及实施后出现了哪些新问题。由于篇幅关系，以下7个落地实践不作详细展开，后续会有发布7篇独立的文章。
产品设计进化：从人主导到人智协同的全链路 AI Native 实践
钟曜戎，阿里云智能集团产品管理总监
我们在实践中越来越明确地感受到，产品设计文档的生产已经不再是瓶颈，真正稀缺的是产品判断和对客户的理解。因此，我们没有只做一个生成 PRD 的工具，而是重新梳理了产品设计的完整价值链，并在底层建设一套贯穿全链路的知识体系。
目前，约三分之二的需求不再需要人逐条查看，价值判断准确率达到 90% 以上，需求响应时长下降 45%，积压处理效率提升 50% 以上；约 80% 的 PRD 已经由 AI 生成；一份端到端产品体验测评的产出时间，也从 4 小时缩短到 30 分钟。
代码审查进化：从通用审查到领域专家，Kitta 代码审查智能体的实践
周远航，阿里云智能集团技术专家
相关数据已经给出提醒：软件行业 CVE 提报总量增长 394%，高危漏洞增长 811%；代码 Bug 率上升 9%，平均 PR 体积增加 154%，评审时间增加 91%。在龙蜥社区，两个主要内核发行版本的月度 PR 合入量，两年间增长了 8.9 倍。因此，AI Native 研发不能止于用 AI 写代码，还需要构建贯穿代码生产、验证和交付的 Agentic CI，代码审查正是其中的第一道质量关口。真正进入大型开源项目后，我们发现 AI 可以看懂一段代码，却不一定看得懂一个项目。它不了解项目长期形成的领域知识、研发方式和流转规则，也不知道什么情况下应该提醒人、什么情况下应该保持克制。
围绕这些问题，我们把 Kitta 分三步建设：先从 GitHub、LKML 和项目仓库的真实历史中，提炼评审原则、典型缺陷模式和项目惯例；再用"流程定义看哪里、知识决定怎么看"的双轮定制，适配不同项目的研发语境；最后通过离线评测和线上真实行为持续校准。
目前，Kitta 在六大领域取得了 17%---30% 的审查质量提升，并已在龙蜥社区服务 ANCK 内核发行版，累计审查 7 万多个补丁，门禁准确率达到 97%，代码合入率达到 62%。
▍代码修复进化：从报警到自动修复，PolarDB-X 的 Loop 工程实践
盛涛涛，阿里云智能集团高级研发工程师
我曾经处理过一个 Bug，最后真正修改的只有两行代码，但查日志、看监控和分析问题就花了一整天。为了复现问题，我只能在各种会议的间隙中抽空反复调试，前后接近一周才完成，之后还要补测试用例、跟进代码评审。如果 AI 只帮我写那两行代码，节省不了多少时间。我们希望交给它的，是从报警到修复交付的整个过程。
为此，我们通过已有的 API 和 CLI，让 Agent 自主查询监控、日志和实例拓扑等信息。对于缺少现成工具的存量平台，就让 Agent 参考已有实现，分析网页请求和认证方式，再把需要的功能封装成 CLI。在运行验证方面，我们基于 Java 调试接口重新实现了适合 Agent 调用的 JDB CLI，支持结构化返回、会话管理和指定线程断点；同时，将大体量 Heap Dump 的分析能力服务化，并提供 PolarDB-X Zero 秒级临时实例和 K8s 完整集群两类复现环境。
目前，这套流程已在云端持续运行，100% 的报警会先由 Agent 做首轮分析和处理；半年内，我们从上万次报警中识别并记录了 200 多个缺陷，其中超过 70% 能够稳定复现，并由 Agent 完成修复后进入评审。这些实践让我们形成了三条工程启发：研发系统要可调用，研发过程要可验证，任务还要能在云端 7×24 小时持续运行。
研发协作进化：从编码提效到端到端交付，云通信的人机协作实践
赵彬，阿里云智能集团高级研发工程师
传统研发中，编码只是需求、方案、测试、发布和验收之间的一环。当编码速度大幅提升，而前后环节仍靠人来衔接时，工作只会更快地堆积到下一个人工节点。于是，我们把目标从单点的编码提效，调整为端到端交付。首先要解决的是 Agent 之间如何协作。
目前，这套云端数字分身驱动的自动化交付流水线可以 7×24 小时运行，已经覆盖国内短信、智能语音、智能调度和国际短信四条业务线。单个分身可并行处理 3---4 个需求，通过门控的简单需求中，约三分之二可以实现端到端自闭环。每次交付后，我们还会审计流程、产物和 Agent 的执行情况，把有效经验写回知识库。过程中我们也走过弯路：急着上模型，低估领域黑话和历史知识的复杂度，也曾被上下文幻觉影响判断。
全域运维进化：从手工造障到规模化量产，STAROps 的评测基准实践
楼海斌，阿里云智能集团技术专家
我们认为一条完整的运维评测数据，应该同时包含执行轨迹、配套条件和核验依据，并做到环境绑定、时间绑定和完整因果链。STAROps 采用四个 Agent 分工协作：ScenarioAgent 负责选题，EnvironmentAgent 负责构建环境，BuildAgent 负责注入故障并提取证据，SupervisorAgent 负责质量体检；人则负责确定目标、制定验收标准和完成终审。线上发生过的真实问题，也可以通过机制还原、等价重放和信号对齐，被重新构造成评测集。我们从质量、覆盖、区分度、规模和新鲜度五个方面检查每一条数据。
目前，平台已经积累 1400 多条评测数据，根因评测集半年增长到原来的 10 倍以上，从 3 月的 58 条增至 9 月的 838 条，覆盖 100 多类根因故障。故障注入只是整个过程中的一步，真正困难的是保证每一条数据都可验证、可沉淀，并且能够持续跑通。只有先把这件事做好，智能运维的能力提升才有可信的衡量基础。
组织进化：Agentic SOC 安全产品自进化背后的组织重构实践
任懿，阿里云智能集团高级安全专家
随着越来越多的改进由 Agent 自主完成，人需要提前设定目标、质量、权限和停止条件四类边界。技术闭环跑通后，我们也开始调整组织：把产品、研发和安全整合进同一个团队，每个需求由一名 Owner 从目标定义负责到结果验收，产品体验、工程交付和安全效果按照同一组标准并行推进。传统串行方式约 51 天的排期，由此缩短到约 14 天。岗位边界也开始围绕结果向前、向后延伸，但这并不意味着人人都要做所有事情。标准明确、可评测、可回滚的任务，由 Agent 执行、人审批；跨领域但风险可控的任务，由 Owner 借助 Agent 闭环；高风险、高歧义或不可逆的任务，仍由专业人员主导。阶段性数据中，需求平均周期从 50.9 天降至 13.8 天，窗口内吞吐率从 63.9% 提升到 98.9%，ARR 增长超过 100%。
我们的体会是，只重构技术还不够。当 Agent 已经围绕最终结果运行，组织也需要围绕同一个结果，重新建立共同目标、统一验收、贯穿责任和风险分工。
产品运营进化：从流程驱动到 Agents 数字人团队的增长实践
王希正，阿里云智能集团高级产品运营专家
我们判断，产品上市与增长也已经进入 Agentic 时代。Gartner 与 Salesforce 的调研显示，AI 承担的营销工作占比将从现在的 16% 增长到 2028 年的 36%。内容生产、GEO 优化和获客等环节的 AI 应用比例都在提高，但新的问题也随之出现，例如流量归因更加困难，内容更新又常常跟不上产品迭代。
我们的应对方式，是从流程驱动转向 Agent 协作。过去，一次完整的营销 Campaign 往往需要筹备数月；现在，一周内就可以跑完。人的精力分配也随之改变：过去主要投入物料生产，现在大约 20% 用于生产协作，80% 用于评判和决策。我们组建了一支营销增长的 Agent 数字员工团队，由 2 个自然人、1 个 Leader Agent 和 6 个 Worker Agent 组成。6 个 Worker Agent 分别负责内容选题、内容创作、商机管理、经营分析、产品知识和流量优化，共同运行产品上市全流程、新功能发布、商机管理和数据分析四条主要管线，协同产品、研发、架构师、运营等 100 多个角色，实现约 10 倍提效。
仍处于早期阶段
七个样板间采用了不同路径。云通信把部分责任绑定在员工的数字分身上，Agentic SOC 尝试由一名 Owner 贯穿原有职能边界；Kitta 和 STAROps 更关注证据、门禁与可重复评测；产品和运营团队则在调整工作节奏和分工。
这些案例都涉及 Agent 进入生产后，流程与责任如何同步调整。各团队仍在分别界定目标、权限、验收和追责方式，目前没有统一做法。从现有案例看，团队开始把更多精力放在问题定义、上下文质量、结果验收和责任划分上，也在尝试将个人经验整理为 Context、Skill、Eval、Harness 或平台能力。这些做法能否跨团队复用，仍需更多生产数据验证。
一次论坛不足以得出结论。接下来的七篇专题将分别回到每个样板间，介绍问题背景、流程调整、门禁设置、失败处理和当前边界。