处理AI-Native 组织的架构范式迁移：从超级个体到智能体协同这类问题时，先确认目标场景，再按步骤核对配置或玩法细节。

## 一、一个反直觉的困局

过去两年，单兵作战效率的提升有目共睹。一个会用 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 奇点智能产品大会上的分享，结合个人在架构演进方向的理解整理而成。","createTime":1786514477,"ext":{"closeTextLink":0,"comment_ban":0,"description":"","focusRead":0},"favNum":0,"html":"","isOriginal":0,"likeNum":0,