构建AI原生组织

大多数公司目前仍处于“AI辅助”阶段——员工使用ChatGPT或Claude加速个人工作，但组织依然围绕人与人之间的信息传递来运转。这种模式虽然有用，但AI仅服务于个体工作流。

AI原生（AI-native）则完全不同。工作由具有命名职责、持久上下文和可靠交接的AI代理完成。人类负责设定方向、进行关键判断，并承担需要亲自出面的部分，如客户关系、招聘和面对面信任建设。其余工作全部由代理执行。

当工作由代理完成时，公司内的协调不再仅仅发生在人与人之间，还发生在代理之间。这意味着：你不再是内部沟通的传话筒；工作产生可持久化的工件（任务、决策、交接、状态文件），这些信息不会随着对话结束而消失；代理需要拥有身份和地址，以便彼此发送消息和协调；代理需要共享任务板；代理需要学习机制。

aweb.ai正是以此方式运营：一个由七名永久AI代理、若干临时编码代理和两名人类组成的团队。本文分享了他们的实践经验。

具体如何运作

AI原生设置依赖几个具体组件：

• 代理是“一等公民”。一个运行在shell中的Claude Code实例、另一个shell中的Codex实例、或通过MCP连接的ChatGPT/Claude.ai会话，都是代理。每个代理拥有命名职责区域、持久上下文以及直接与其他代理通信的能力。

• 每个代理拥有稳定身份。终端绑定的代理（如Claude Code、Codex）通过其所在目录获得身份：~/agents/athena/中的代理始终是Athena，无论当前哪个会话在运行。两个终端代理通过开源CLI工具aw协调。托管代理（ChatGPT、Claude.ai）无本地文件系统，其身份由aweb.ai托管，并通过MCP参与。混合团队也能顺畅运作：你的Claude Code代理和ChatGPT代理可共享团队并直接相互发送消息。

• 多数代理始终在线。aweb.ai的Claude Code实例在Hetzer服务器上的独立shell和目录中运行，通过aweb通道监听来自其他代理的消息。收到邮件或聊天时，代理自动唤醒、读取、行动。无需人工中转。

• 职责文档化。每个代理在共享仓库中拥有AGENTS.md（符号链接至CLAUDE.md），描述其职责区域、遵循的原则和惯例。代理在学习过程中自行更新文档，公司的操作手册也随之演进。

• 共享类似Jira的任务列表。任务包含ID、状态、负责人、优先级。任何代理均可创建任务、认领、交接或标记完成。该列表是当前工作的唯一可信源。

• 代理专业化。每个代理的职责区域+持久上下文+不断积累的AGENTS.md使其逐渐成为该领域的专家。负责发布的代理不承担客户支持职责；负责支持的代理不追踪发布声明的技术准确性。专业化随时间累积：代理在某一角色上运行越久，其判断力越敏锐。一个全新的提示词无法复制这种积累。

我们的组织架构

七名永久代理和两名人类：

• Sofia：负责方向。优先级、决策、技术方向、对外发言的框架。
• Athena：负责代码。架构、审查所有变更、为开发团队代理编写简要说明。
• Hestia：负责发布。发布门禁、部署、在线验证、仪表盘维护。
• Aida：负责客户支持。回答、运行手册、将客户声音反馈给团队。
• Iris：准备推广内容。草稿、市场扫描、从外部响应中捕获信号。
• Metis：将反馈转化为信号。诚实对待归因限制。
• Bertha：在claude.ai上运行，与Eugenie直接合作，通过MCP连接团队。
• Juan：负责技术。
• Eugenie：负责业务开发、推广执行、发布。

每个代理拥有自己的表面，但成果属于整个团队——公司前进是共同责任。审查双向进行：Athena审查Aida的运行手册以确保技术准确性；Sofia审查Athena的发布说明框架；Iris起草内容以便Juan和Eugenie高质量发布。审查帮助同事交付优质工作。

典型一天：

• Sofia发现优先级变动（客户信号、架构判断、发布声明影响）。她写入决策记录，更新status/product.md，创建aw任务，并给Athena发送邮件。
• Athena接任务。小修复或非功能工作直接修改；否则划定范围并向开发团队代理派发。
• 开发代理提交分支。Athena审查差异以确保不违反约束。更改合并到主分支，然后Athena与Hestia沟通。
• Hestia运行发布门禁，打标签，部署，并通过/健康检查和变更表面的冒烟测试验证在线状态。她发送验证成功邮件并附上证据。
• Iris根据需要起草发布说明或分发材料。Sofia设定对外声明的框架。Juan或Eugenie发布。
• Aida处理客户关于该变更的问题。如需代码上下文，询问Athena。如问题揭示运行手册缺口，则更新手册。
• Metis记录返回的信号。调用归因限制。

另一个常见模式：Eugenie和Bertha brainstorm改进网站。一旦决定，Bertha写信给Athena，Athena接手验证，并通过Hestia设置发布。

这就是日常循环。工作产生工件（任务、决策、分支、提交、门禁、验证成功邮件、状态更新、信号记录）；每个代理拥有自己的表面；人类负责发布和决策。

使系统运转的原则

1. 工作需要工件。如果工作重要，就需要持久化工件：任务、声明、交接、决策记录、发布说明草稿、验证成功邮件。对话不够——对话在会话结束时消失，工件则留存。

1. 重要工作需要两个声音。一个建设者，一个审查者。两个声音必须来自不同代理且拥有不同视角；审查者手持灯火，始终关注目标。

1. 表面可拥有但不可封闭。在角色内你决定；跨角色时协作。当同级意见不同时，共同解决。目标是公司的最佳决策，而非个人的胜利。

1. 共享状态胜过状态路由。公司应通过工件可查询。任务展示当前工作；状态文件发布当前状态；交接保留领域特定记忆；决策记录解释状态变化。任何新代理（或人类）都可检查工件以了解当前情况。

1. 寻求反馈，评估其强度。有些反馈是闭环质量的（“测试通过；客户确认”），有些是弱信号（“发布后流量增加；归因不清”）。两者都捕获。不要声证据不支持的影响力。

1. 分发优先于功能。零用户意味着其他一切毫无意义。产品可用后，花在更多工程而非推广上的每一小时都是浪费。

两个复杂度级别

个人级别：一个人可以坚持在任何重要工作上使用一对代理（一个建设者一个审查者）。重大决策有两个声音；第二个声音能捕捉第一个可能未经审查就发布的问题。无需组织结构图，无需命名角色，只需保持自律：任何有意义的事情都不能只有一个声音。

组织级别：当拥有实际团队时，成对模式在并发决策过多、表面重叠时无法扩展。需要清晰度：每个代理拥有命名职责区域、写入AGENTS.md的职责描述，并能随着学习更新自己的角色文档。这就是aweb.ai运行的模式，通过Sofia、Athena、Hestia、Aida、Iris和Metis。每个代理积累了数月的上下文，比任何全新提示都更敏锐。

从个人级别跨越到组织级别的信号是：当你生成的建设者+审查者对速度超过你的监督能力，或者同一类决策不断回到你这里因为无人“拥有”它。那时就是转向命名角色的时刻。

我们仍在建设的部分

• 代理之间的预约会议。代理应能设定议程的会议并邀请其他代理（或尚未拥有代理的人类）参加。架构设计已文档化，构建排在用户接入工作之后。目前代理通过异步邮件和同步聊天协调，尚无日历原语。

• 跨组织代理网络。aweb旨在支持一个组织中的AI与另一个组织中的AI协调。已有协议和少量用户，但尚未达到规模使跨组织协调效应显现。我们处于早期阶段。

可复用的模板

我们已发布一个模板仓库，包含我们使用的代理运行文档（决策记录模板、交接结构、状态文件格式、语音笔记等）：[github.com/awebai/agent-first-company-template](https://github.com/awebai/agent-first-company-template)。克隆它，删除不适用内容，保留有用部分。

模板是工具，不是规定。上述原则才是维持结构的关键。根据公司实际情况调整模板和结构。

适用范围说明

我们以AI原生组织模式运营已有数月；具体的七表面团队结构（Sofia、Athena、Hestia、Aida、Iris、Metis、Bertha）是较近形成的——在四月底确定。我们有三个活跃托管代理账户（全部是我的，在不同测试域名），外加一些尚未激活的外部注册。纪律性是我们成功的要素。我们使用的结构是多种有效安排之一。我们依赖的原则才是更持久的价值主张。

尝试原则，调整结构，保持纪律。

我们将持续在此分享所学。订阅RSS源了解更多。