跳转至

AI Native 团队协同：知识底座＋Agent＋人三层闭环

Ch04.191 AI Native 团队协同：知识底座＋Agent＋人三层闭环

📊 Level ⭐⭐ | 14.3KB | entities/ai-native-team-collaboration-knowledge-base-agent-human-taobao-2026.md

AI Native 团队协同：知识底座＋Agent＋人三层闭环

摘要

天猫技术团队（书牧）从"单点提效遍地、全局增量不见"的困境出发，提出 AI 提效的真正瓶颈是协同而非单点产能，核心论断是：AI 时代生产侧的串联者从人换成 Agent——这是"AI Native"与"AI 辅助"的分水岭。在此基础上给出 AI Native 团队的理想形态：以完整业务单元为边界的"知识底座＋Agent＋人"三层闭环，并论证软件是被固化的知识（TBox/ABox 本体论视角），实现该形态的关键瓶颈不是协同工具（方向已清楚）而是存量业务的知识底座（构建方法难、知识在人脑、底座自治存活三坎）。

核心框架

消费侧 vs 生产侧二分

一切生产活动最终满足人的需求，而原始需求本质稳定（马斯洛需求不变），变的是满足方式。据此把业务切成两类：

  • 消费侧（直面人的需求）：演进本质是交互方式升级（报纸→门户→信息流→AR/脑机接口），未来朝"个人助理"（贾维斯式）方向走，接管"最后一公里"需求，高度个性化；终端永远是人，"以人为本"不被技术动摇。
  • 生产侧（B 端，组织与串联生产）：没有"终端是人"的锚，完全是当下技术水平的产物——有什么技术就长出什么流程分工系统，技术每升级一轮就被重写一次（手工作坊→流水线→ERP/OA→互联网化/移动化）。

串联者转换：AI Native 的分水岭

过去几十年生产侧软件的隐含设计前提是"人是串联者"：表单让人填、看板让人看、审批流让人点，流程本质是一连串由人完成的传递、判断和衔接（人靠"泛化性+容错性"天生适合串联）。AI 时代最大的变化是串联者从人换成 Agent：

  • AI 辅助：流程骨架不动，串联者还是人，只是某个环节加挂 AI 功能（在旧流程上加挂能力）。
  • AI Native：把串联者整个换掉，由 Agent 承担传递、判断和衔接，并围绕"Agent 是串联者"这个新前提重建流程本身。

推论：会消亡的不是"软件"这个笼统概念，而是那些把"人是串联者"当设计前提的软件——表单、报表、审批流，以及大量"等人来操作下一步"的内部系统环节。生产侧形态注定被重构（不是在旧骨架修补，而是围绕新串联者重新长一遍）。

三层闭环：知识底座＋Agent＋人

以完整业务单元为边界的理想形态：

  • 底层：统一知识底座——沉淀业务规则、业务流程、领域知识和规范约束（"这个业务究竟怎么运转"本身）。
  • 中层：各司其职的 Agent 群——运营/产品/研发 coding/测试/运维/客服等，都从知识底座取知识，承接并串联自己环节的工作；还需依赖工具和技能（查数据/调系统/跑流程/触发变更）。知识底座决定"知道什么、该怎么做"，工具技能决定"能做到什么"。拆分为多 Agent 而非大而全：不同 Agent 感知知识范围、服务范围、权限和安全要求不同，拆分后上下文相互隔离，评测和优化可独立迭代（运维 Agent 感知代码层知识+调用 normandy/sunfire/arthas；内部答疑 Agent 可回复代码级错误定位；外部客服 Agent 要专业话术）。
  • 顶层：人——不再是流程里逐个传递信息的"接力棒选手"，而是与 Agent 群围绕同一业务目标协同：定方向、做判断、处理例外、把新知识沉淀回底座。角色边界会变模糊（全栈融合目前主要发生在执行层如写代码），但专业深度决定面对 AI 产出时能做哪一层的专业决策——判断 AI 给的复杂工程/架构方案靠不靠谱的能力将更稀缺，非"全栈"可覆盖。

闭环运转示例：业务需求由业务/PD 借助业务/产品 Agent 基于知识底座产出 MRD/PRD → 研发 Agent 定位领域/应用/规则拆解技术方案 → 人在协作空间（项目群）与 AI 协同、关键节点确认判断 → 编码/测试/发布由 Agent 串联执行 → 新决策与知识回流底座；监控报警触发运维 Agent 自动排查定位、止血操作由人决策；答疑 Agent 基于知识底座自动回答、不确定时群里 at 成员确认（Qteam 的 Q仔实践）；用户 bug 自动记录 Aone 缺陷并触发研发 Agent 自主修复；运营 Agent 产出业务状况报告供老板决策。

软件是被固化的知识（TBox/ABox 视角）

知识底座包含两类内容，对应本体论的经典区分：

  • TBox（类型层定义）：业务规则（"是什么、要遵守什么"的陈述性知识）+ 业务流程（"按什么次序做"的程序性知识）——都是知识。
  • ABox（事实层）：运转中产生的一笔笔订单、商家、用户等具体事实。完整知识底座须同时含 TBox 和 ABox。

软件在此模型里不是必需品——抽象地看，业务完全可以由 Agent 直接在知识底座上运转。软件之所以需要，是因为 Agent 动态运转在某些地方不够用（交互体验/确定性/性能/成本/安全/合规审计），于是把一部分业务规则和流程"固化"成产品规则和产品流程，落到软件研发流程（含 AI Coding）。软件是被固化的知识；"把知识固化成软件"本身又是条业务流程（研发流程），同样可由 Code Agent 在知识底座上完成——AI Coding 本质就是这个固化动作。生产侧被重构但不会被清空：确定性逻辑以产品规则/流程形态固化在软件层，源头始终是知识底座。未来"沉淀"动作本身也变：过去交付一套软件，往后交付更多是"知识"（含 Skill）；过去集成交付端到端软件系统，往后更多是给 Agent 交付一件件工具。

两件事：知识底座是瓶颈，协同工具是基建

  • 协同工具（长期看不是瓶颈但很重要）：通用基础能力，理论上跨团队协同需无缝，不适合各业务重复造，但当下基础团队无完整方案。已有探索：Aone 团队的 Devix、Qteam 团队的 Qoder 系列、企业智能的数字员工账号、ideawork 等，均不完善属探索阶段。已见关键概念雏形：业务空间（划定业务闭环边界的核心容器，Devix 产品空间类似）/ 参与者（人类成员+各类 Agent，关联技能和知识）/ 任务（项目/需求/话题）/ 频道（人与 Agent 协同入口，IM/Web/通用助手；传统入口在钉钉，未来也许在通用助手）/ 产物（协同沉淀结果）/ 知识底座（每个业务空间管理的知识+数据，是业务护城河）。批评：企业级业务的复杂度和瓶颈往往不在写代码一段（拿半托管超链跨团队项目为例，商业逻辑/方案取舍在多个角色间讨论清楚极其耗时）；别被"Coding 变快了"的幻觉带偏（简单需求全自动交付对全局提升有限；研发为"完美写代码"反过来要求 PD 更完整 PRD 反而把产品设计与研发割裂，协同成本一点没省）；协同工具不该只停在研发流程（AI Coding），应往更左侧的需求侧、业务侧走。
  • 知识底座（真正长期卡住全局的瓶颈）：不通用、不可复制，每块业务都得自己长出一套，做得越久的传统业务越难。

存量业务知识底座三坎

新业务/新团队（白纸）可从第一天按"知识底座＋Agent＋人"组织，不用还历史债；真正的硬骨头是存量业务：

  1. 构建过程和方法难：系统架构是历史一块块长出来的（边界/耦合/字段含义留痕迹）；在划定范围里把知识底座扎扎实实构建出来——抛开历史包袱重新讲清"业务到底怎么运转"——是最难也最有价值的部分，结果理论上应反过来指导组织和架构长成什么样。
  2. 大量知识在系统之外、在人脑里：最关键的规则、"为什么当年这么定"的来龙去脉、只有老人才清楚的例外大多是隐性的。原则：尽量把每条知识锚定到权威事实来源，能从代码/配置/数据自动生成和校验的绝不靠人肉维护；越靠人脑那端的越要专门设计沉淀机制外化；能不能自治取决于知识离权威来源有多近。
  3. 底座必须能"自己活下去"：业务天天变，靠人肉更新维护很快烂掉/过期/没人信；须靠自动化+人工确认保鲜（自治能力），而非架构师责任心硬扛。本体论提供了描述"规则/流程/数据及其关系"的语言，但落地难点仍是在具体存量业务里建起来并持续转下去。

边界问题：知识底座以多大范围为单位建/闭环？划太大规则流程千头万绪难收敛，建到一半陷在复杂度；划太小凑不成完整闭环，Agent 一串联频繁跨边界又退回"靠人对接"。边界还关乎组织结构（需求依赖商品详情/交易等平台团队就没法只从"我这个业务"视角闭环）。作者认为两年前架构组讨论的业务大图/产品树等概念与知识底座本质是一回事，AI 背景下更有必要性和可行性。

为什么现在绕不开

"把一个业务彻底讲清楚、让它可被复用"一直很难，过去因串联者是人而被"扛"过去（知识不全/流程不清/文档过期靠人补位、对接、救火，问题被掩盖）。AI 时代串联者换成 Agent，遮羞布被揭开——Agent 没法像人那样靠经验和默契补位，只能在知识底座上运转，底座有多清楚它就能跑多远。"建知识底座"从可一直拖着的事变成绕不开的必选项；迈不过这道坎的大公司迟早被没有历史包袱的创业公司（白纸优势，存量之难不用还）用"知识底座＋Agent"跑出数倍效能甩在身后。

与库内相关实体关系

相关实体

→ 原文存档