第18章一人多Agent公司的核心思维

本章前置检查：

□ 已完成OpenClaw与Hermes的基础学习（第一篇和第二篇）
□ 理解双Agent协作的基本模式（第15章）
□ 了解共享记忆的概念（第16章）

本章预估总时长：2.5小时

本章难点提示：

18.2节（岗位映射）是抽象思维，建议先通读，后续案例会反复实践。
18.3节的三层架构是全书的方法论骨架，建议画图加深理解。
18.5节（设计Agent团队）是本章的核心产出，建议动手为你的业务画一张Agent组织架构图。

🎯 本章教学目标：从企业管理视角理解多Agent系统的价值，掌握岗位→Agent的映射方法，能够独立设计一个一人多Agent公司的三层架构，并遵循核心原则搭建最小可行团队。

18.1 从公司视角看Agent

🎯 本节目标：将抽象的多Agent系统类比为一家真实公司，建立直观理解。

预计时长：0.5小时

为什么要把Agent比作员工？

在单独学习OpenClaw或Hermes时，我们关注的是工具、配置、API。但当多个Agent协同工作时，更合适的视角是组织管理——每个Agent就像一个虚拟员工，有自己的职责、技能、工作流程和协作方式。而你，就是这家公司的CEO。

这种类比不是修辞，而是方法论：你可以复用现实中的管理经验（分工、授权、监督、复盘）来设计多Agent系统。

Agent即员工

公司要素	多Agent系统中的对应
CEO/管理者	你（人类）
部门经理	OpenClaw Team Lead Agent
普通员工	执行特定任务的Agent（写作、数据分析、代码审查等）
实习生	子Agent（临时委托，任务完成后自动归档）
公司制度	AGENTS.md中的约束、工作流
企业文化	SOUL.md中定义的核心价值观、沟通风格
培训手册	Skill（操作流程文档）
工作笔记	共享记忆（MEMORY.md, USER.md）
周报/复盘	Hermes的定期自省和技能自我改进

一人多Agent公司的独特优势

零管理成本：不需要招聘、培训、发工资、处理人事纠纷。
无限可复制：可以随时创建新的Agent实例，且配置完全一致。
永不疲倦：7×24小时工作，无情绪波动，严格执行规则。
知识沉淀：成功经验自动固化为Skill，不会因“员工离职”而丢失。

龙马注：这个类比不是比喻，是真的可以照着公司管理制度来设计你的Agent团队。我甚至给每个Agent写了OKR（第3章的“目标”字段），然后每周让OpenClaw汇总各Agent的完成情况，自己坐在旁边点评。效果出奇地好。

🛠️ 实践任务（本节）：画出你理想中的“一人多Agent公司”组织结构图，标注每个Agent的角色名称和大致职责。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

18.2 企业岗位→Agent角色的映射

🎯 本节目标：掌握将真实企业的职能部门和岗位映射为Agent角色的方法，为后续案例和量化篇打下基础。

预计时长：0.5小时

映射原则

职责单一：一个Agent只做一类事（如只写代码，不兼做设计）。
协作明确：Agent之间的输入/输出格式约定清晰。
权限最小：每个Agent只拥有完成职责所必需的工具和记忆访问权限。

通用映射表（不限行业）

企业岗位	Agent类型	推荐平台	职责
总经理/项目经理	Team Lead	OpenClaw	接收用户需求，拆解任务，分配给专业Agent
研究员/分析师	专业Agent	Hermes	深度研究、数据分析、报告生成
执行岗（操作类）	执行Agent	OpenClaw	按固定规则执行重复性任务（如发送邮件、更新数据库）
客服/接待	交互Agent	OpenClaw	处理用户咨询，引导至正确流程
审计/合规	监督Agent	OpenClaw（只读）	检查其他Agent的执行日志，报告异常
知识管理员	记忆Agent	Hermes	维护共享记忆，定期蒸馏经验

如何为你的业务创建映射

步骤：

列出你业务中的所有工作流（如“发布一篇文章”包括选题-写作-配图-分发）。
将每个工作流拆解为独立的岗位（如“选题专员”“写手”“设计师”“分发员”）。
判断每个岗位是偏确定性执行（OpenClaw）还是偏学习研究（Hermes）。
为每个岗位编写AGENTS.md和SOUL.md（参考第3章）。

沈飞注：在量化场景中，这个映射会非常细致：因子挖掘、回测、风控、交易执行、绩效归因……每个都可以是一个Agent。甚至同一个因子挖掘流程里，还可以细分“数据处理Agent”“因子计算Agent”“因子评价Agent”。但初学者先从5个以内核心Agent开始，不要过度设计。

🛠️ 实践任务（本节）：选择一个你熟悉的业务（如“每日新闻摘要生成”），按照上述步骤拆解出至少3个岗位，并填写映射表。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

18.3 一人多Agent公司的三层架构

🎯 本节目标：理解入口层、执行层、进化层的分工与协作，掌握三层架构的设计原则。

预计时长：0.5小时

架构全景图（文字描述）

     用户（飞书/Telegram/Web）
                ↓
┌───────────────────────────────┐
│  入口层 (OpenClaw)             │
│  - 多渠道消息接入               │
│  - 会话管理与路由               │
│  - 用户认证与设备配对            │
└───────────────────────────────┘
                ↓
┌───────────────────────────────┐
│  执行层 (多Agent团队)           │
│  - 专业Agent（写作/分析/运维）   │
│  - 子Agent（临时任务）          │
│  - Agent Teams协作             │
└───────────────────────────────┘
                ↓
┌───────────────────────────────┐
│  进化层 (Hermes)               │
│  - 跨会话记忆（MEMORY.md）      │
│  - 自动生成Skill               │
│  - 经验蒸馏与团队复用            │
└───────────────────────────────┘

各层职责详解

入口层（OpenClaw）：

唯一与用户交互的界面。
负责解析用户意图（简单任务直接回答，复杂任务路由到执行层）。
管理所有会话状态和用户偏好（短期记忆）。
不执行深度任务，也不学习。

执行层（多Agent团队）：

包含多个专业Agent，每个Agent只负责一类任务。
Agent之间通过ACP或共享记忆协作。
可以动态创建子Agent处理临时任务。
所有Agent的执行结果返回给入口层，由入口层推送给用户。

进化层（Hermes）：

不直接面向用户，也不执行实时任务。
定期（或按需）从执行层吸收经验，沉淀为共享记忆和Skill。
负责长期记忆的维护、技能质量治理、知识蒸馏。
当执行层遇到新问题时，可以请求进化层提供建议（通过ACP）。

设计原则

单向依赖：入口层依赖执行层，执行层依赖进化层，反向不依赖（避免循环）。
松耦合：每一层可以独立升级、替换，不影响其他层。
故障隔离：进化层宕机，入口层和执行层仍可工作（只是不能学习新知识）。

龙马注：这个三层架构不是理论模型，我已经在生产环境跑通了。入口层是OpenClaw Gateway开着飞书和Telegram，执行层是6个常驻Agent（写作、分析、代码、搜索、翻译、天气），进化层是一个单独的Hermes实例，每天凌晨2点被Cron唤醒，执行记忆审查和技能改进。三个月没重启过，稳定。

🛠️ 实践任务（本节）：画出你自己的三层架构图，标注当前已经实现了哪些组件，哪些还需要补充。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

18.4 核心原则

🎯 本节目标：掌握设计多Agent系统的三条核心原则，并能在实际配置中应用。

预计时长：0.2小时

原则一：职责单一（Single Responsibility）

每个Agent只做一类事，且只做自己职责范围内的事。

反例：一个Agent既负责写代码，又负责测试，还负责部署。→ 职责混乱，难以维护。
正例：开发Agent、测试Agent、运维Agent各司其职。

配置检查：查看Agent的AGENTS.md，如果“职责”列表超过5条，考虑拆分。

原则二：协作明确（Clear Coordination）

Agent之间的交互必须有明确的输入/输出格式、通信协议和超时处理。

实践：

使用ACP的delegate模式，约定返回的JSON结构。
在AGENTS.md中写明“当收到XX格式的请求时，应该怎么做”。
设置合理的超时时间，避免互相等待死锁。

原则三：可追溯（Traceability）

每个Agent的决策和执行过程必须可审计、可回放。

实践：

所有ACP请求记录日志（包含request_id）。
重要操作（如交易、删除文件）写入审计日志。
使用分布式追踪（第17.3节）关联跨Agent调用链。

沈飞注：在量化系统中，可追溯不仅是技术需求，还是合规要求。我们要求每个交易信号都必须能追溯到产生它的因子和参数，Agent日志里必须包含这些信息。如果审计时发现缺失，整个信号会被标记为无效。

🛠️ 实践任务（本节）：检查你现有的Agent配置，是否违背了上述三条原则？记录下需要改进的地方。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

18.5 设计你的Agent团队：角色体系、分工原则与协作模式

🎯 本节目标：学会一套系统化方法，从零开始为你的业务设计多Agent团队。

预计时长：0.4小时

五步设计法

第一步：业务流分析

列出你的核心业务场景（如“内容创作”“电商运营”“量化交易”）。
绘制业务流程图（从触发到结束的所有步骤）。

第二步：角色拆解

将流程中的每个步骤抽象为一个“角色”。
为每个角色命名（如“选题策划”“素材收集”“文章撰写”）。

第三步：技能匹配

判断每个角色需要哪些能力（搜索、分析、生成、执行）。
匹配OpenClaw或Hermes的工具集和Skill。

第四步：协作设计

定义角色之间的数据传递格式（文件、JSON、消息）。
确定同步还是异步（ask/ delegate）。

第五步：权限与记忆设置

为每个Agent设置最小权限（工具白名单、文件访问范围）。
确定哪些记忆需要共享，哪些需要隔离。

案例：小型内容创作团队（5个Agent）

Agent	类型	职责	输入	输出	记忆
选题Agent	Hermes	监测热点，生成选题	关键词	选题列表	共享选题库
调研Agent	Hermes	收集素材，整理大纲	选题ID	Markdown大纲	共享素材库
写作Agent	Hermes	根据大纲撰写文章	大纲	初稿	个人风格记忆
配图Agent	OpenClaw	生成/搜索配图	文章关键词	图片URL	无
分发Agent	OpenClaw	发布到多个平台	文章+图片	发布状态	无

协作流程：

选题Agent产出选题，写入共享记忆（L2）。
调研Agent读取未处理的选题，产出大纲，更新状态。
写作Agent读取大纲，产出初稿，写入共享文件。
配图Agent和分发Agent依次触发（通过OpenClaw Cron或用户指令）。

龙马注：这个设计法我每次搭建新业务时都会用。先不写任何配置，只用思维导图画一遍，等角色拆解清楚了，再动手写AGENTS.md非常快。建议你也养成习惯。

🛠️ 实践任务（本节）：为你的一个业务场景（例如“个人周报自动生成”）应用五步设计法，产出角色表。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

18.6 从单人试航到舰队：扩展Agent团队的标准化流程

🎯 本节目标：掌握当业务规模扩大时，如何系统化地增加新Agent而不破坏现有架构。

预计时长：0.4小时

扩展的信号

什么时候需要考虑增加新Agent？

现有Agent的AGENTS.md中“职责”列表超过5项。
某个Agent经常因为任务类型混杂而需要频繁切换模型或工具集。
用户反馈“响应慢”且定位到是单Agent处理队列积压。

标准化扩展流程

步骤1：分析瓶颈

使用第17章的性能分析方法，确定是哪个环节阻塞。

步骤2：拆分职责

将阻塞Agent的职责拆分为2-3个更细粒度的角色。
例如：“研发Agent”拆分为“代码生成Agent”“测试Agent”“代码审查Agent”。

步骤3：创建新Agent

为每个新角色编写AGENTS.md和SOUL.md。
配置工具权限（通常比原Agent更严格）。

步骤4：调整协作

修改原Agent的AGENTS.md，移除拆分出去的职责。
配置新的路由规则（OpenClaw侧），将相应任务委托给新Agent。

步骤5：迁移记忆

如果新Agent需要继承原Agent的部分记忆，使用共享记忆的L2/L3机制迁移。
保留原Agent的记忆不变，新Agent从共享库中学习。

步骤6：灰度验证

先让新Agent处理10%的流量（通过OpenClaw的路由权重）。
观察一周，确认准确率和性能达标后，逐步切换到100%。

扩展检查清单

新Agent的AGENTS.md中是否定义了清晰的职责边界？
新Agent是否只拥有完成职责所需的最小权限？
原Agent的配置文件是否已更新（移除拆分职责）？
路由规则是否支持按比例分配流量？
共享记忆的读写冲突是否已考虑（乐观锁）？
审计日志是否记录了新旧Agent的交接过程？

沈飞注：在量化系统中，因子挖掘团队的扩展我们用了这个方法：最初一个因子研究Agent负责全流程，后拆分为“数据清洗Agent”“因子表达式生成Agent”“回测验证Agent”“因子评价Agent”。每个新Agent上线前都在隔离环境中运行一周，用历史数据验证结果与旧Agent一致后才正式替换。这套流程保证了策略研发的稳定性。

🛠️ 实践任务（本节）：假设你当前有一个“全能开发Agent”，请按照上述流程设计将其拆分为3个更专业Agent的方案。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

第18章参考资料与扩展阅读

一人公司：从0到1搭建你的AI员工团队（阿里云开发者社区） https://developer.aliyun.com/article/1730226
Agent角色设计模式：职责单一与协作模式 https://hermes-agent.nousresearch.com/docs/design-patterns
多Agent系统架构设计原则 https://openclaw.com/blog/multiagent-architecture
从单Agent到多Agent：扩展策略与避坑指南 https://www.volcengine.com/docs/87732/2277062

第四篇综合任务（第18章完成后）

任务：完成以下所有检查项，并记录输出。

画出你设想的一人多Agent公司组织结构图（三层架构）。
针对你的一项日常业务（非量化），完成五步设计法，产出角色映射表。
对照核心原则，评估你现有Agent配置的合规性，列出至少2条改进项。
（可选）如果你已经有多个Agent在运行，设计一个扩展计划（增加一个新Agent）。

完成后，保存设计文档，命名为chapter18_team_design.md。

龙马的评审：

“18.5节的五步设计法非常实用，我在给新员工培训时就用这个。但注意，第一步“业务流分析”不要做得太细——你不需要画到“点击按钮”这种粒度，而是到“角色”粒度。比如“用户发送消息→选题Agent产出选题→调研Agent收集素材→写作Agent生成文章”，这4步就够了。每步对应一个Agent。

另外，扩展流程中“灰度验证”这一步很多个人开发者会跳过。我的经验是：即使只有自己用，也值得做——你可以先在命令行里手动触发新Agent，确认没问题后再改路由规则。不要在生产环境直接替换。”

沈飞的评审：

“18.6节的扩展流程在量化回测中完全适用。我们因子挖掘团队从1个Agent扩展到5个，用了整整两个月。每次扩展前都要先跑对比回测：新旧两个Agent分别处理同一批历史数据，比较结果差异。只有当差异小于阈值时，才上线新Agent。

另外，不要过度设计。初期一个全能Agent能处理的事情，不要强行拆分成5个。只有当性能或维护性成为瓶颈时，才考虑扩展。记住：简单是一种美德。”

下一章预告：第19章案例一：一人内容创作公司 —— 我们将把第18章的方法论应用到具体场景中，搭建一个完整的AI内容创作团队，涵盖选题、调研、写作、配图、分发全流程。同时，我们会在最后指出这个案例与量化公司（因子挖掘、策略研发）的类比关系，为第五篇做铺垫。

文章版权归作者所有，未经允许请勿转载。

THE END

搭建一人公司给自己的书一人多Agent公司
# openclaw # 一人公司 # Hermes # AI量化

第18章一人多Agent公司的核心思维

第18章一人多Agent公司的核心思维