一、一个反直觉的困局

过去两年，单兵作战效率的提升有目共睹。

一个会用 AI 写代码的开发，产出可能翻三五倍；一个用 AI 做调研的产品经理，一天能跑完过去一周的竞品分析。把这些点连起来看，理论上组织整体效率应该有数量级的跃升。

但实际数字并不支持这个推论。多数企业的 AI 投入回报曲线，在过了个人效率红利期之后，开始走平。

问题出在哪？工作流里的摩擦损耗没有被解决。

一个人用 AI 把自己的事干快了，但成果流转到下一个环节时，还是会卡在审批队列里，等在上游数据没对齐的状态里，耗在跨部门对齐的沟通成本里。

单点速度快了十倍，整条链路的瓶颈却可能纹丝不动。

这事放到系统架构的语境下就好理解了——这本质是一个单服务吞吐量与全链路吞吐量不匹配的问题。

你把一个微服务的响应时间从 500ms 优化到 50ms，但如果调用链上的其他服务还是 500ms，端到端延迟几乎不变。

组织效率的优化思路也一样。瓶颈在哪里，优化就该打在哪里。

二、核心矛盾：个人体感 vs 系统吞吐

从 360 内部推进 AI 落地的经验来看，真正的分水岭不在于模型能力有多强，而在于 AI 是从"个人工具"切入组织，还是从"组织流程"切入组织。

这两条路径在设计哲学上是根本不同的。

以个人为中心的模式

以个人为中心的模式（个人助手路径），解决的是"我快不快"的问题。

它把人的私有上下文、工作偏好、个人知识库作为核心资产。这个模式天然高效，因为不需要和任何外部系统做契约对接——你调的 AI 是你的，和公司流程没关系。

以组织为中心的模式

以组织为中心的模式（岗位智能体路径），解决的是"链路通不通"的问题。

它要求 AI 具备组织身份，拥有岗位权限，能接入业务流程的特定节点，并且每一步操作都留下可审计的痕迹。

这个模式慢、重，但可治理。

两种模式的差异

打个比方：个人助手像自己抽屉里的瑞士军刀，想怎么用就怎么用；岗位智能体像装配线上的一台数控机床。

你不可能让它今天切模具、明天焊电路板，但它在自己的工序上稳定、精确、不出格。

一个常见的踩坑场景是：把个人助手直接当岗位智能体推上线。

比如某个员工用自己的 AI 调了一版合同的审核标准，第二天换个人来问，AI 把上一份合同的涉密信息全吐出来了。

这不是技术问题，是架构没划清边界。

三、三条架构基线

在 360 的实践中，落地 AI-Native 组织，需要先把下面三条架构基线立住。

这三条不是口号，每一条背后都有血的教训。

3.1 身份与权限：给 Agent 一个"工牌"

这是最容易踩的坑，也是最容易被跳过的环节。

绝大多数企业用 AI 的第一步，是找模型、搭对话界面，然后直接把 API 接到业务系统上。

这样做出来的 Agent，在日志里显示的操作人就是"某某某的 AI"。出了问题追责追谁？操作合规怎么审计？

更规范的做法是：智能体应当在组织通讯录中拥有独立身份。

它需要具备自己的数字工牌、清晰的岗位归属，以及经过审批的权限集。

当它在 CRM 里修改某条客户记录时，日志中应记录为“岗位 Agent-X 于某时某刻执行了某操作”，而不是“张三的 AI 改了一条数据”。

这一步不是简单的技术对接，它要求对企业的统一身份认证体系做深度改造。

• HR 的通讯录要能挂 Agent
• OA 的审批流要能认 Agent 的身份标识
• 权限中心要对 Agent 的操作做 RBAC 映射

规模越大的企业，这一步越重，但也越绕不开。

3.2 异构纳管：别指望一个框架统一所有

大型组织里，不同部门用不同厂商的智能体框架是必然的。

财务可能买的金蝶的智能体，人事可能用的是另外一个平台搭出来的，子公司可能又跑在开源框架上。

指望用一套框架、一个大模型吞掉所有场景，在工程上是不现实的。

360 的做法是建了一层连接器。

不管是自己内部的智能体工厂（SEAF）、第三方的 Openclaw、Hermes，还是商用的闭源模型，都通过同一组接口对接到协作平台上。

在平台层做统一身份注入、统一权限管控、统一调用路由。

从架构上看，这就是一个典型的适配层模式。

上层统一编排，下层多态接入。和微服务网关的设计思路是一样的——后端服务的实现可以千差万别，但网关只认统一的协议和鉴权格式。

3.3 双轨协作：会话型与流程型各有适用场景

人机协作有两条轨道，不能混用。

会话型协作适合探索性任务。

多个 Agent 进到一个项目空间里讨论方案、拆解需求、互相质询。这种模式灵活，但不可控。

一旦上下文膨胀，Agent 之间的信息交叉就会产生"上下文污染"。

360 团队踩过一个坑：做了一个多 Agent 项目协作模块，让几个人和几个 Agent 在同一个空间里自由会话。

结果 Agent 之间互相引用彼此的错误推理，越跑越偏。

后来加了一条约束：在项目空间里，只调用该项目已关联的专家 Agent、Skill 和上下文切片，把无关信息全部隔断。

流程型协作则是另一套逻辑。

它适合确定性任务：报销审批、合规校验、数据核对。

这种场景下，Agent 是作为 BPM 工作流的一个节点存在的。

原来的流程节点只能指派人，改造后可以指派给特定 Agent。流程跑到了 Agent 节点，数据自动推过去，处理完把结果塞回流程引擎。

这两种模式没有优劣之分，适用场景不同。

一个工程经验是：确定性越高，越适合流程型；探索性越高，越适合会话型但必须加隔离策略。

四、关键架构决策：让谁"持证上岗"

前面讲的几条基线，最终都指向一个核心问题：什么样的 Agent 才算合格上岗？

360 内部给岗位型 Agent 设了硬指标：评测得分超过 85 分才能上线。

这里的评测不是跑几个 Benchmark 样本题，而是针对具体业务场景做全链路考核。

新上的 Skill 要经过评审、压测、灰度验证，流程和招一个新人没什么两样。

还有一个很容易被忽视但非常关键的细节：Agent 的“记忆”和人的记忆必须严格隔离。

个人助手在使用过程中积累的经验、偏好以及上下文信息，默认都属于私有内容，不能未经控制地自动同步或共享给组织。

而岗位智能体所需要依赖的业务知识、操作规范和标准流程，则应当通过正式的评审与沉淀机制进入 Skill 库，而不是直接从某个人的聊天记录中提取出来使用。

从治理角度回顾整个架构，大致可以抽象成三层：

• 基础层：统一身份 权限 审计日志。Agent 持证上岗，每一步操作可追溯。
• 连接层：异构 Agent 适配、协议转换、路由调度。屏蔽底层框架差异。
• 协作层：会话型项目空间 vs 流程型工作流节点，双轨并行，按任务类型切换。

五、一个务实的 ROI 视角

最后说一个容易被忽略的点：Token 消耗的 ROI 不是线性均匀的。

360 给的内部观察是：探索性工作（需求研讨、方案推演、架构设计）的 Token 投入产出比并不高。

因为前期变量太多、方向反复调整，AI 又倾向于给"讨好型"的答案，来来回回消耗大量 Token，核心结论往往还是人自己想出来的。

确定性工作（PRD 转材料、代码生成、数据核对）的 ROI 则极高。

花十块钱的 Token 省一天的人力，是常态。

这一条对架构设计的启示是：AI-Native 组织的架构设计，应该把确定性工作尽量往流程型轨道上推，把探索性工作的上下文限制在可控范围内。

不是所有工作都适合交给 Agent，替人省时间的地方和省不了的地方要分清楚。

----

本文基于 360 数智化集团产品总监廖百成在 2026 奇点智能产品大会上的分享，结合个人在架构演进方向的理解整理而成。