从 AI Native 个人到 AI 协作组织

从 AI Native 个人到 AI 协作组织，中间隔着一套新的操作系统

一家公司给所有员工开通 ChatGPT、Claude、Codex，最先发生的通常是局部提速：邮件写快了，原型做快了，代码产量上去了。

然后，老问题换了一种形式回来。AI 写完的方案还要到处补背景；产品、设计和开发继续在不同版本之间对齐；Agent 能生成代码，却不知道服务之间的关系；每个人都在积累对话记录，组织没有因此多获得一份可以复用的能力。

工具普及了，协作成本仍然存在。

我读完 OpenAI、Uber 和 Palantir 最近公开的实践后，感受最深的也不是哪一家用了更强的模型。它们都在做一件更费力的事：把原本藏在人脑、会议和系统缝隙里的判断，改造成机器可读、可执行、可评估的组织基础设施。

这才是 AI Native 个人走向 AI 协作组织的分水岭。

AI 不会自动消除组织混乱。它会先把目标不清、知识断裂和责任模糊放大出来。

三个工程师，五个月，一百万行代码

OpenAI 做过一个很激进的实验。

一个小团队从空 Git 仓库开始，用 Codex 开发一款真实的软件产品。五个月后，仓库接近一百万行代码，约 1500 个 PR 被创建并合并，产品有数百名内部用户。最初推动项目的只有三名工程师。应用逻辑、测试、CI、文档、可观测性和内部工具都由 Codex 生成，团队估算完成速度约为人工编写的十倍。

这组数字很容易让人把注意力放在“零人工写代码”上，但原文里更重要的细节发生在实验早期：团队一开始推进得比预期慢。

Codex 没有突然变笨。它缺少的是完成复杂工作的环境。工具不完整，抽象层不清楚，日志和界面无法直接观察，知识也没有按照任务需要组织起来。人类工程师由此换了一种工作方式：遇到失败时不再接过任务手写代码，而是追问系统缺了什么能力，怎样把这项能力变成 Agent 能看见、能使用、能被约束的东西。

后来，Codex 可以启动独立应用实例，操作页面，读取 DOM 和截图，查询日志、指标与链路，复现 Bug，修复后再次操作应用验证结果。一次运行可以持续数小时。人的瓶颈也从“代码写不完”转移到“质量来不及验”。

这段经历揭示了一个常被忽略的事实：

AI 产能扩大以后，最稀缺的资源不再是执行速度，而是组织给出清晰意图、可靠环境和有效反馈的能力。

个人 AI 和组织 AI，中间隔着什么

一个人使用 AI，许多条件可以留在脑中。

他知道客户说的“简单一点”具体指什么，知道哪份数据已经过期，知道老板会卡在哪个措辞上，也知道这个任务做到什么程度就能交付。提示词没有写全时，他会随手补一句；结果跑偏时，他能凭经验把方向拉回来。

这种能力很难直接复制给十个人、一百个人和一组 Agent。

新人看不到老员工脑中的经验。Agent 看不到没有接入的聊天记录。部门之间也不会天然共享同一套目标、状态和验收标准。个人效率因此停留在个人身上：人一换、会话一关、任务一交接，大量上下文就消失了。

AI 协作组织需要把个人工作时自然完成的五件事，外化成一套公共系统：

1. 业务目标：为什么做，完成条件是什么。
2. 共享上下文：有哪些事实、状态、历史和规则。
3. 执行工具：AI 能读取什么、调用什么、修改什么。
4. 评估反馈：怎样判断结果，失败后回到哪里。
5. 权限审计：谁发起、谁执行、谁审批、怎样追溯。

模型位于这套结构中间。模型升级会提升局部能力，五层结构决定这份能力能否进入组织、稳定运行并留下积累。

Context：文档很多，不代表 AI 拥有上下文

不少团队理解的“上下文建设”，是把几十份文档塞进知识库，再让 AI 搜索。

文档只能回答“写过什么”。组织任务还需要知道：哪一份是当前事实，谁拥有决定权，任务处于哪个状态，过去为何放弃某个方案，当前结果将交给谁，下一步允许触发什么动作。

这也是 OpenAI 放弃巨大 AGENTS.md 的原因。他们试过把大量规则写进一个入口文件，结果很直接：上下文窗口被说明书占满；当每条规则都被标成重要，Agent 反而找不到重点；文档很快过期，也难以机械检查。

团队后来把约百行的 AGENTS.md 当作地图，把架构、产品规范、执行计划、质量标准、可靠性和安全规则拆进结构化 docs/。复杂任务的计划、进度和决策日志与代码一起版本化；专门的 Linter 和定时 Agent 检查文档是否过期、缺少链接或偏离真实系统。

这里有一个关键变化：知识管理从“存资料”变成“维护一套当前可用的决策地图”。

Uber 遇到的问题规模更大。它的 Agent 面对数亿行代码、数千张数据表和大量内部系统，很多推理轮次花在寻找信息上，而非解决问题。Uber 因此建设了 AI Context Graph：2400 万个节点、8000 万条边，连接服务、团队、事故、PR、架构文档、部署记录和数据资产等 30 多个内部系统。

在 Uber 公布的一组相同任务对比中，接入图谱的 Agent 用 38 秒得到正确答案；没有图谱时，它搜索了约 20 分钟，答案仍然错误。这是 Uber 在自身环境中的结果，不能直接外推到所有公司，但它说明了一个机制：Agent 找到相关关系的能力，往往比一次塞进更多文字更重要。

上下文至少包含三层：

• 事实层：客户、订单、代码、内容、数据等当前状态。
• 决策层：目标、规则、历史选择、责任人与验收条件。
• 行动层：当前允许调用的工具，以及动作会影响哪些系统。

文档库覆盖第一层的一部分。组织要让 Agent 参与工作，还要补齐后两层。

有效的上下文让 AI 在此刻知道哪些事实有效、什么目标优先、下一步可以做什么。

Harness：给 AI 一双眼睛、一双手和一块记分牌

拥有上下文的 AI 仍可能只是一个聪明的顾问。它能提出建议，却无法观察现实状态，也无法把建议变成动作。

Harness 是 Agent 的工作环境。它通常包含三类能力：

• 眼睛：页面、日志、指标、截图、数据库状态。
• 双手：代码工具、业务 API、MCP、自动化工作流。
• 记分牌：测试、规则、验收条件和结果指标。

OpenAI 的实验能持续推进，依靠的正是这套环境。Codex 收到任务后，可以读取当前仓库，复现问题，记录失败画面，实现修改，再次驱动应用验证，处理构建失败和评审意见，达到条件后提交合并。高层任务被变成一条可观察、可重试的执行链。

Uber 还碰到了一个更具体的问题：工具太多也会伤害 Agent。

它的统一 MCP Gateway 汇集了 1000 多个 MCP Server。如果按照常规方式把工具定义全部预加载进会话，安装 100 多个工具就会带来约 5 万到 7 万 Token 的 Schema 开销，而且后续每轮上下文还会反复携带。

Uber 改用 CLI 动态解析和 Tool Search。Agent 先搜索工具目录，确定需要什么，再按需加载和调用。工具仍然统一管理，Agent 不必背着一本几万 Token 的“工具黄页”工作。

这件小事很能说明组织级工程和个人使用的区别。个人会话里，多放几个工具看不出问题；当调用量、工具数和 Agent 数量扩大后，上下文成本、选择准确率和权限治理都会变成系统问题。

Eval：从“生成了多少”改成“交付了什么”

生成式 AI 很容易制造繁荣：更多代码、更多文档、更多设计稿、更多内容。

产出数量上涨，不等于组织价值上涨。代码可能增加维护成本，文档可能彼此冲突，内容可能重复，Agent 也可能用很高的推理成本完成一个不重要的动作。

Eval 的意义，是把组织的判断标准从人脑里提取出来，变成可以重复运行的验收机制。

Uber 没有只计算 Token 和调用次数。对于托管 Agent，它进一步观察“每单位结果的成本”：每个已合并 PR 的成本、每次代码评审的成本、每次告警处理的成本；质量侧还跟踪回滚率、F1、平均恢复时间等指标。

它的代码评审 Agent uReview 使用真实 PR 和已知 Bug 建立基准，按照难度分层，同时衡量精确率、召回率、F1、评审成本、延迟、超时和噪声。模型选择由真实任务上的成本、质量和可靠性共同决定。

这比问“哪个模型排行榜第一”更接近经营。

对不同业务，Eval 的定义也完全不同：

• PRD 评审要检查证据、历史实验、跨部门依赖和上线准备度。
• 客服 Agent 要检查答案依据、解决率、升级人工的时机和合规风险。
• 内容系统要检查事实、逻辑、重复度、读者收益、视觉证据和平台规则。

没有 Eval，组织只是在批量生产未经检验的可能性。

Eval 不能等到交付前才出现。目标模糊时，Agent 不知道往哪里走；完成条件模糊时，它也不知道什么时候停。好的 Eval 从任务开始就参与工作，它同时定义方向、边界和结束条件。

Loop：一次错误，能不能让整个组织学会

Eval 判断结果，Loop 负责继续行动。

局部 Loop 很容易理解：测试失败，Agent 读取日志、修改代码、再次运行，直到通过或升级给人。

组织级 Loop 更难。一次失败暴露出的知识缺口、工具缺口或规则缺口，需要回写到系统，让后面的任务直接受益。

OpenAI 团队早期每周五要拿出约 20% 的时间清理所谓“AI slop”。人工大扫除无法跟上 Agent 的产出速度。后来，他们把架构偏好、边界规则和质量要求编码成可执行的原则，再让后台 Agent 持续扫描偏差、更新质量评级、提交小规模重构。

人的品味只表达一次，系统随后持续执行。这才产生复利。

Uber 也把 Agent 运行中的摩擦记录下来，尝试从执行轨迹中生成 Skill 更新。Palantir 的 Ontology 则记录数据、逻辑和动作形成的决策链，让一次人机协作产生的方案能够成为后续流程和模型的上下文。

所以，Loop 的价值远大于“失败后再试一次”。它要回答的是：

这次为什么失败？缺少的东西应该补进任务提示、知识、工具、Eval，还是权限规则？补完以后，下一位员工和下一个 Agent 是否还会重犯？

个人会从错误中积累经验。AI Native 组织要让系统从错误中积累经验。

Governance：当 AI 开始行动，责任不能留在对话框里

AI 写一份草稿时，风险还比较有限。Agent 能查询数据、修改代码、发送消息、调整订单之后，“它能不能做”必须与“它被谁授权做”同时解决。

Uber 给出的案例很具体：一名值班工程师向 Oncall Agent 发起任务，Oncall Agent 再调用 Investigation Agent，后者通过 MCP Gateway 读取日志或操作工具。下游系统如果只看末次调用，就无法知道最初是谁发起、经过哪些 Agent、为何获得权限。

Uber 使用 Agent Registry 记录 Agent 与工作负载的对应关系；Security Token Service 为每一跳签发有效期只有几分钟、限定目标系统的凭证；Actor Chain 把“人 → Agent → Agent → 工具”的完整链路写入令牌；MCP Gateway 再根据人员身份、Agent 身份、工具风险和敏感数据策略决定是否执行。

这套系统解决的是一个朴素的问题：AI 做完一件事后，公司能否准确回答谁授权、谁执行、调用了什么、为什么被允许。

权限和审计也决定自主程度。Palantir 的做法是让 Agent 先“暂存”改变工单状态、推送资源重分配方案等动作，再交给人审核。随着流程通过测试、日志积累和风险下降，组织可以扩大自动执行范围；条件变化时，也可以立即收回。

自主程度是一条由证据支持、可以伸缩的权限曲线。

Palantir 给出的另一种答案：围绕决策组织企业

OpenAI 和 Uber 的故事从软件工程出发，Palantir 的 Ontology 更接近企业运营。

传统数据平台关心表、字段和指标。真实业务运行却围绕对象与决策展开：哪张订单受供应中断影响，哪个工厂还有产能，哪项调整会增加运输成本，谁有权批准资源重分配。

Palantir 把数据、业务逻辑、可执行动作和安全策略放进同一层。Agent 看到的不再是一堆孤立表格，而是会随现实变化的企业对象，以及围绕对象可以采取的行动。

这里最有启发的地方，是它把“决策血缘”也当成数据。一次决策参考了哪些信息，调用了哪条逻辑，谁与哪个 Agent 参与，执行了什么，结果又如何——这些记录会成为后续优化 Agent 的材料。

企业最昂贵的知识，常常不在制度文件里，而在一次次例外处理和跨部门权衡中。Ontology 试图把这些散落在流程接缝里的经验照亮。

从这个角度看，AI Native 组织建设的对象是企业的决策系统。

我做编导智能体时，也遇到了同一个问题

我之前做一站式 AI 编导系统，最初看到的是一条被工具切碎的内容生产链。

灵感放在笔记里，选题开一个 AI 对话，文章再开一个对话，视频脚本放进另一个文件夹，封面和素材散落在本地，发布时重新整理标题、简介和标签，平台数据则留在各自后台。

每个环节都可以用 AI。每次交接又要重新解释账号定位、目标受众、历史选题、事实证据、平台规则和当前状态。耗时最多的动作，逐渐从“生成一段文字”转向“搬运并重新建立上下文”。

我把编导工作拆成了一条围绕作品运行的链路：

1. 身份与定位：先明确哪个账号、服务哪类人、长期讲什么。
2. 选题发现：读取评论需求、热点、对标案例和历史作品，排除重复命题。
3. 策划创作：建立项目和 Brief，把证据、观点、结构、审核状态放在同一作品下。
4. 制作与成片：文章、视频脚本、字幕、录屏、封面和最终文件沿用同一份作品上下文。
5. 发布执行：针对不同平台生成物料、排期、提交并登记状态。
6. 数据复盘：采集阅读、互动、评论和发布明细，把结果送回下一轮选题与校准。

中间连接这些模块的，是几个持续流动的对象：账号定位、作品 ID、当前版本、证据和素材、生产状态、审核结论、发布记录与复盘数据。

举个具体例子。一条选题进入系统后，写作环节读取账号定位、目标用户、相关资料和历史内容，输出带来源的母稿；视频环节从母稿提取口播与镜头需求，不能重新编一个故事；封面环节读取同一核心命题和真实素材；发布环节检查标题、简介、标签、比例与文件状态；发布后的评论和数据再进入复盘，影响同类选题是否继续、标题承诺是否成立、哪种呈现方式需要调整。

在这条链上，Eval 也有了具体位置：选题阶段查重，文章阶段审事实、逻辑和读者收益，视觉阶段核对图片是否解释正文，发布阶段检查素材与平台约束，复盘阶段比较承诺与真实数据。任何节点不通过，就回到对应环节修复，不把“生成成功”当成“可以交付”。

人仍然保留几个关键控制点：核心命题是否成立，公开事实是否可靠，最终表达是否代表作者，发布动作是否授权。Agent 接管中间大量查找、生成、检查、转换和登记工作。

这段实践让我重新理解了“编导智能体”四个字。它把原本依赖某个编导记忆和经验的工作方式，外化成一条团队与 Agent 都能加入的生产系统。

中小团队从哪里开始

大多数团队不需要先建 2400 万节点的图谱，也不需要复制 OpenAI 的纯 Agent 代码库。

可以先找一条满足三个条件的任务：发生频率高，结果可以验收，失败成本可控制。然后依次回答：

• 任务最终交付什么，而非 AI 要生成什么？
• 完成任务需要哪些当前事实与历史决策？
• AI 要观察哪些状态，调用哪些工具？
• 哪些规则可以自动检查？
• 哪些动作必须由人批准？
• 失败原因回写到哪里，下一次怎样直接使用？

先跑通一条闭环，再扩展相邻流程。第一条流程会逼迫团队处理最实际的问题：文档是否可信、接口是否稳定、谁负责验收、规则是否能写清、失败能否追溯。

这些问题解决以后，AI 才从个人技巧变成组织能力。

AI Native 的第一场革命，发生在组织内部

过去，很多管理问题可以靠一个经验丰富的人兜住。信息不全，他会去问；流程断了，他会推动；规则模糊，他会凭判断处理。

Agent 无法长期依赖这种隐形兜底。它迫使组织把目标说清楚，把知识整理出来，把工具接通，把质量标准编码，把权限和责任留下记录。

AI 带来的第一场组织革命，会让大量长期依赖默契、记忆和救火维持的工作失去藏身之处。

一家公司的 AI 上限，最终取决于它能否把少数人脑中的判断，沉淀为整个组织可以调用、验证和持续改进的系统能力。

模型会继续升级，今天领先的能力很快会变成公共能力。长期拉开组织差距的，是模型之外那部分缓慢而艰难的建设：共享上下文、执行环境、Eval、Loop，以及与它们一起成长的责任体系。

给员工开通 AI 账号，只是采购完成。

当一次人的判断能够被系统记住，一次失败能够修改后续流程，一个 Agent 能在边界内完成任务并对结果负责，AI Native 转型才算开始。

—— 月明水清深

参考资料

• OpenAI：Harness engineering: leveraging Codex in an agent-first world
• Uber：Running a Software Factory Efficiently at Uber Scale
• Uber：AI Prototyping Is Changing How We Build Products at Uber
• Uber：Lessons from Building a First-Pass AI PRD Reviewer
• Uber：Solving the Identity Crisis for AI Agents
• Palantir：Why create an Ontology?