如果你已经把 Agent 用到了实际工作流里大概率会遇到这样一个卡点你确实能让 AI 完成某一类任务比如写文案、写代码、整理资料但多任务之间相互衔接、上下文反复切换时产出就开始变得碎片化。你需要在不同对话窗口里来回搬运结论手动帮 AI“对齐信息”最后甚至分不清哪个版本才是最新结果。这个问题在最近的 Agent 热潮里被反复提起。很多人以为“一人公司”就是一个人同时打开一堆 AI 工具让它们各自干活。但从落地效果看真正能跑的并不是“一堆工具”而是一套有角色、有流程、有交付物标准的协作架构。基于这个思路Hermes Agent Team 的五角色架构提供了一种比较清晰的解法可以把一个人需要扮演的产品、技术、运营、质检等工作拆成五个各司其职的 AI Agent再通过统一的任务上下文串联起来。这篇文章会围绕 Hermes Agent Team 五角色架构与一人公司模型 v3.1 展开讲清楚它到底解决什么问题、五角色之间如何协作、v3.1 的版本设计逻辑从哪几个方面改进了旧方案并且给出一套可落地的最小示例代码。即使你还没有接触过 Agent 编排框架也可以照着流程先跑通一个“任务拆解 → 执行 → 质检 → 交付”的闭环。1. 这篇文章真正要解决的问题先聊一个真实场景独立开发者想做一个小程序但一个人的精力有限。需求梳理、技术方案、UI 文案、后端接口、测试用例、发布说明这些工作如果全部靠自己做一周能出一个原型已经算快。如果你尝试让 AI 帮忙最常见的做法是打开一个 AI 对话窗口让它写需求文档复制需求文档再打开另一个对话窗口让它设计数据库把数据库设计复制到第三个窗口让它写接口代码写完后自己凭经验检查逻辑有没有漏洞。这个流程表面上用了 AI但本质上仍然是“人来当总线”。AI 只是被动的生成工具所有上下文传递、任务拆分、质量验收都压在你自己身上。一旦需求复杂到一定程度这种模式就会崩上下文丢失。每个新窗口都要重新解释背景AI 经常忘掉前面的决策。角色混乱。同一个模型时而写代码、时而写文案、时而做测试输出风格没有边界。没有验收机制。生成结果到底行不行靠人肉眼判断没有结构化检查。Hermes Agent Team 这样的五角色架构核心价值就是把“人当总线”改成“流程当总线”。它通过多个 Agent 分工协作让每个角色只负责自己最擅长的那一段同时把任务状态和上下文存放在一个共享上下文里。这样人只需要接收最终结果或者在关键节点做审批。所以这篇文章最值得读的读者不是刚接触 AI 的纯新手而是已经在用 AI 提效、但觉得效率遇到瓶颈的内容创作者、独立开发者、小团队技术负责人。2. 从“单人工具流”到“一人公司”五角色架构为什么更有价值很多关于 Agent 的讨论把重点放在了模型能力上比如“这个模型更强了所以 Agent 更聪明了”。但在实际工程里Agent 系统的瓶颈往往不在单点模型能力而在结构设计。传统架构下一个人是系统的绝对中心用户输入 → 人拆解任务 → 人调用AI生成 → 人检查 → 人返工 → 人交付五角色架构下人变成了“目标输入者”和“最终审批者”用户输入目标 → CEO角色拆解 → PM角色细化 → 技术角色执行 → 运营角色包装 → QA角色验收 → 人审批交付这个转变看起来只是多加了几个中间步骤但它带来的实际变化是第一任务不再是零散对话。每个角色面对的都是结构化任务单而不是一次又一次的“帮我写一下”。结构化任务单里包含了目标、约束、输出格式、验收标准模型生成时被限制在更明确的边界里产出质量更稳定。第二上下文可以被记录和回溯。如果某个环节出了问题你能看到是哪个角色、基于哪段上下文做的决策而不是重新开一个窗口碰运气。第三一个人真的可以管理多个“员工”。你扮演的是管理者而不是执行者。你不需要亲自写每一版文案、每一段代码你需要的是给团队下达目标、在关键节点验收、对不合格结果打回重做。这就是“一人公司模型”的核心。它不是让你只靠一个 AI 聊天窗口完成所有事而是让你用一套组织化的方式把一个人能撬动的产出规模放大。3. 五角色架构的基本分工与协作方式“五角色架构”在不同实现里有不同的命名方式。在 Hermes Agent Team 的 v3.1 设计里比较常见的一套划分是统筹者、产品经理、技术实现者、运营交付者、质量审查者。五个角色对应了“一人公司”在业务闭环中必须覆盖的五种职能。3.1 统筹者CEO Agent统筹者是整个 Agent Team 的入口负责接收用户目标判断任务的可行性拆解成几个阶段并且决定哪个角色在哪个时间点介入。它不负责具体执行也不负责最终的细节打磨。它的核心职责是把模糊想法变成可执行任务列表。举个例子用户输入“我想做一个 AI 周报生成器”。统筹者不能直接开始写代码它必须先理解目标用户是谁核心功能是什么交付范围是一份方案、一个原型还是一套代码有哪些约束条件如果任务过于巨大比如“我想做一个完整的电商平台”统筹者应该主动拆成多个阶段而不是让所有角色一次性开工。3.2 产品经理 AgentPM Agent产品经理 Agent 是“把任务说清楚”的角色。它负责把统筹者的任务列表进一步细化成需求说明包括功能清单、用户流程、优先级、验收标准。在传统开发里产品经理输出的文档会直接影响开发效率。在 Agent 协作里也一样。PM Agent 输出的需求描述越清晰后面的技术实现者越不容易跑偏。PM Agent 的典型输出包括用户故事功能列表页面或接口的优先级成功标准。它本质上是一个“翻译器”把统筹者的目标翻译成执行者听得懂的语言。3.3 技术实现者 AgentEngineer Agent技术实现者负责把需求变成可运行的产物。在内容型的“一人公司”里它可能是文案写手在产品型的“一人公司”里它可能是代码生成器在运营型的场景里它可能是海报文案生成器。这个角色需要理解 PM 输出的需求同时遵守一定的技术规范。比如如果任务是写 Python 接口它需要输出完整的代码而不是一句“建议使用 Flask”。在 Hermes Agent Team 的分工里技术实现者必须明确自己“只做实现”不做需求变更也不做最终验收。3.4 运营交付者 AgentOperator Agent很多 AI 工作流会忽略“交付”这个环节。运营交付者做的事情是把技术实现者的产出包装成用户真正能消费的成果。比如你让团队做了一个小程序方案技术实现者输出的是接口设计和代码逻辑运营交付者则负责补充介绍文案、使用说明、发布计划甚至生成演示用的 prompt 和示例数据。这个角色解决的是“做完了但是别人看不懂、用不起来”的问题。3.5 质量审查者 AgentQA Agent质量审查者是最后一道防线。它和前三类角色不同不是来创造的而是来挑错的。QA Agent 会检查输出是否满足 PM 定义的验收标准技术实现者有没有遗漏关键文件或逻辑运营交付者的文案里有没有明显的错误或误导整个任务链路的上下文是否一致。如果发现问题QA Agent 会把问题退回给对应角色而不是自己做修改。这一点很重要否则角色边界会被打乱。3.6 五角色的协作流程五个角色之间是流水线式协作而不是同时并行。一个最基本的协作流程是统筹者拆解目标 → PM细化需求 → Engineer产出成果 → Operator包装交付 → QA验收每个环节的输出会写入共享上下文后一个角色基于共享上下文继续工作。这样即使某些环节需要人工介入你也能清楚地知道当前卡在哪一步。4. v3.1 版本的核心设计逻辑与改进方向关于 Hermes Agent Team 的 v3.1 版本目前公开资料里没有特别统一的官方文档说明因此这里更多是基于版本号演进的常见逻辑做合理梳理。从 v3.1 这个命名和 Agent 系统设计趋势看新版主要有四个值得关注的设计方向。4.1 多轮任务状态持久化较早的单体 Agent 设计只适合“一轮对话完成任务”。你问一句它答一句没有长期状态。但在五角色架构里一次完整的业务交付可能要经历多个角色、多轮对话如果每一轮都重新加载全部上下文很快会把模型上下文窗口撑爆。v3.1 风格的设计里更强调“任务状态持久化”每个角色产出结果后把结构化摘要写回任务上下文而不是把原始大段文本都保留。比如 Engineer 写了几百行代码存入上下文的可能是文件结构、接口摘要和关键设计决策而不是完整代码。4.2 结构化输出协议为了让多个 Agent 之间能够互相理解v3.1 版本会更强调结构化输出。每个角色在输出内容时必须遵循固定的 JSON Schema 或 Markdown 模板而不是自由发挥。例如 PM 的输出格式可以定义成{ feature: 功能名称, user_story: 用户故事描述, priority: P0/P1/P2, acceptance_criteria: [验收条件1, 验收条件2] }结构化输出的好处是Engineer Agent 可以直接解析这份 JSON 来生成任务清单而不是靠模型自己“意会”。4.3 角色隔离与上下文摘要v3.1 设计里很关键的一点是角色隔离。每个 Agent 只读取与自己相关的上下文片段而不是共享全部信息。这样做有两个好处减少模型幻觉。上下文里不相关的信息越少模型越不容易编造内容节省 Token。每个角色的输入上下文被压缩长任务的运行成本会明显下降。角色隔离的实现方式一般是在共享上下文基础上给每个 Agent 配置一个“可见字段”白名单。4.4 人工审批点配置无论 Agent 多强大完全无人值守仍然有风险。v3.1 版本的设计里更常见的是引入“人工审批点”也就是 Human-in-the-loop。你可以在流程中的任意节点插入审批统筹者拆解完任务后人可以确认方向QA 验收通过后人可以决定是否交付涉及发布、支付、删除等敏感操作时必须人工确认。这个设计不是为了降低效率而是为了防止 Agent 在无人监督的情况下做出错误决策。5. 环境准备与项目结构设计下面进入实操部分。我们用一个最小实现来演示五角色架构的协作逻辑。虽然 Hermes Agent Team 本身可能已经有内部实现但作为技术博客更重要的是让你理解这套模式如何落到代码里。5.1 运行环境建议准备以下环境Python 3.10 或更高版本一个可用的 LLM API例如 OpenAI 的 Chat API或本地部署模型一个 Python 虚拟环境可选的 Agent 编排框架如 CrewAI、LangGraph但本文为了展示核心思路不依赖框架也能跑通。这里要说明不同 LLM 的接口版本变化较快下面的代码以最常用的 Chat Completions 风格为例实际运行时请以你使用的 SDK 官方文档为准。5.2 项目目录结构一个最小的 Hermes Agent Team 项目可以这样组织hermes_team/ ├── main.py ├── context.py ├── roles.py ├── prompts.py └── config.py每个文件的职责如下main.py入口负责启动任务context.py共享上下文管理负责记录任务目标、各角色产出、任务状态roles.py五角色 Agent 的定义prompts.py每个角色的系统提示词config.py模型名称、API Key 等配置。6. 最小可实现五角色 Agent Team 代码示例为了让示例足够直观这里不引入重型框架只用一个简单的 Python 类来实现“角色 Agent”。核心思路是所有角色共用同一个 LLM 调用函数但每个角色有不同的系统提示词和上下文视图。6.1 配置与共享上下文先定义配置文件config.py# file: config.py import os # 以环境变量或配置文件方式读取 LLM_API_KEY os.getenv(LLM_API_KEY, your-api-key) LLM_BASE_URL os.getenv(LLM_BASE_URL, https://api.openai.com/v1) LLM_MODEL os.getenv(LLM_MODEL, gpt-4o-mini) LLM_TEMPERATURE 0.3注意API Key 千万不要写死在代码里更不要提交到 Git 仓库。生产环境建议通过密钥管理服务或者环境变量注入。再定义共享上下文context.py# file: context.py class TeamContext: 共享上下文。保存任务目标、各角色产出和最终结果。 def __init__(self, task: str): self.task task self.state { task: task, ceo_plan: , pm_requirement: , engineer_output: , operator_output: , qa_report: , status: created } def update(self, role: str, content: str): field_map { ceo: ceo_plan, pm: pm_requirement, engineer: engineer_output, operator: operator_output, qa: qa_report } if role not in field_map: raise ValueError(funknown role: {role}) self.state[field_map[role]] content self.state[status] f{role}_done def get_visible_context(self, role: str) - str: 角色隔离每个角色只看到与自己相关的上下文。 if role ceo: return f任务目标{self.state[task]} if role pm: return ( f任务目标{self.state[task]}\n f统筹计划{self.state[ceo_plan]} ) if role engineer: return ( f任务目标{self.state[task]}\n f需求文档{self.state[pm_requirement]} ) if role operator: return ( f任务目标{self.state[task]}\n f技术实现结果{self.state[engineer_output]} ) if role qa: return ( f任务目标{self.state[task]}\n f需求文档{self.state[pm_requirement]}\n f技术实现结果{self.state[engineer_output]}\n f运营交付物{self.state[operator_output]} ) return self.state[task]这里的关键设计是get_visible_context()。QA 角色看到的信息最全因为它需要验收完整链路PM 不需要看到运营最终产出的全部细节Engineer 不需要看到 QA 的检查过程。6.2 角色基类与 LLM 调用定义一个最小 LLM 调用封装llm.py。为了简化我们不单独建文件而是放在roles.py里# file: roles.py import json from openai import OpenAI from context import TeamContext client OpenAI( api_keyyour-api-key, base_urlhttps://api.openai.com/v1 ) def call_llm(system_prompt: str, user_prompt: str, temperature: float 0.3) - str: 统一的 LLM 调用入口。 实际项目中可以把这里换成任意模型服务。 response client.chat.completions.create( modelgpt-4o-mini, temperaturetemperature, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt} ] ) return response.choices[0].message.content注意上面代码使用了硬编码的 API Key这在实际项目中不可取。建议改为从环境变量读取例如使用os.getenv()。6.3 定义五个 Agent 角色接着定义一个 RoleAgent 基类和五个角色类# file: roles.py class RoleAgent: def __init__(self, name: str, system_prompt: str): self.name name self.system_prompt system_prompt def run(self, context: TeamContext) - str: visible_context context.get_visible_context(self.name) output call_llm( system_promptself.system_prompt, user_promptvisible_context ) return output class CEOAgent(RoleAgent): def __init__(self): super().__init__( nameceo, system_prompt( 你是一家公司的统筹者。你的任务是把用户目标拆解为可执行计划。 需要明确阶段、负责人、里程碑和风险点。 输出格式使用 Markdown 有序列表。不要自己执行具体工作。 ) ) class PMAgent(RoleAgent): def __init__(self): super().__init__( namepm, system_prompt( 你是产品经理。基于统筹计划输出需求文档。 必须包含功能列表、优先级、用户故事、验收标准。 输出格式为 Markdown 表格加列表。 ) ) class EngineerAgent(RoleAgent): def __init__(self): super().__init__( nameengineer, system_prompt( 你是技术实现者。基于需求文档输出可运行的技术方案。 如果是代码任务必须输出完整代码并解释关键函数。 不要修改需求范围不要做最终验收。 ) ) class OperatorAgent(RoleAgent): def __init__(self): super().__init__( nameoperator, system_prompt( 你是运营交付者。把技术成果包装成用户可用的交付物。 如果任务是产品方案你需要补充使用说明、宣传语、上线清单。 ) ) class QAAgent(RoleAgent): def __init__(self): super().__init__( nameqa, system_prompt( 你是质量审查者。对照需求文档和验收标准检查交付物质量。 必须输出问题清单、风险等级、修复建议。 如果发现问题明确指出需要打回哪个角色。 ) )在这段代码里五个角色共用同一个RoleAgent基类和同一个 LLM 调用入口唯一的差异就是system_prompt和name。这说明一个关键点Agent 的“角色感”主要来自提示词约束而不是模型本身的差异。6.4 编排五个角色的流程现在写一个简单的 Team 类负责按顺序调度五个 Agent# file: main.py from context import TeamContext from roles import CEOAgent, PMAgent, EngineerAgent, OperatorAgent, QAAgent class HermesTeam: def __init__(self): self.roles { ceo: CEOAgent(), pm: PMAgent(), engineer: EngineerAgent(), operator: OperatorAgent(), qa: QAAgent() } def run(self, task: str): context TeamContext(task) # 阶段1统筹拆解 plan self.roles[ceo].run(context) context.update(ceo, plan) print( 统筹计划 ) print(plan) # 阶段2产品细化 requirement self.roles[pm].run(context) context.update(pm, requirement) print( 需求文档 ) print(requirement) # 阶段3技术实现 engineer_output self.roles[engineer].run(context) context.update(engineer, engineer_output) print( 技术实现 ) print(engineer_output) # 阶段4运营交付 operator_output self.roles[operator].run(context) context.update(operator, operator_output) print( 运营交付 ) print(operator_output) # 阶段5质量审查 qa_report self.roles[qa].run(context) context.update(qa, qa_report) print( 质量审查 ) print(qa_report) return context.state if __name__ __main__: team HermesTeam() result team.run(设计一个面向独立开发者的AI周报工具输出产品方案和技术实现方案)这个编排是串行的前一个 Agent 的输出作为后一个 Agent 的输入上下文。这是最简单也最容易理解的方式。实际工程中你还可以根据任务类型做并行、条件分支、循环重试但核心思路是相通的。7. 运行一个完整任务并验证产出运行方式很简单python main.py如果一切正常你会看到控制台依次输出五个阶段的结果。判断任务是否成功的标准不是“有没有报错”而是结果是否满足以下条件统筹计划里包含阶段拆解而不是只有一句话需求文档里有功能优先级和验收标准技术实现里给出了具体方案或代码不是泛泛而谈运营交付物包含了使用说明或包装文案QA 报告里列出了风险点和打回建议。在开发阶段建议先用一个很小的任务跑通流程比如“设计一个 To-Do 应用的最小功能清单”。不要一开始就丢一个大规模需求进去否则你没有参照物来判断每个角色是否正常工作。如果某个阶段输出不符合预期例如 PM 输出的是“这是一个非常好的想法”而不是结构化需求那么优先检查对应角色的 system_prompt 是否明确约束了输出格式。提示词里的“必须包含”“不要”“输出格式为”这类指令对结果稳定性影响很大。8. 常见问题与排查方法多 Agent 系统最容易出的问题不是单个 Agent 答错而是协作链路中的上下文断掉、角色越权、重复生成和 Token 浪费。下面整理几个高频问题。问题现象可能原因排查方式解决方案后续 Agent 答非所问上下文太长被截断或前一角色输出格式不规范查看共享上下文里每个字段的长度检查前一角色输出是否被截断对超长结果做摘要给每个角色增加输出长度限制设置更严格的 JSON 输出格式多个角色输出高度重复角色提示词边界不清晰都把自己当全能助手检查 system_prompt 是否明确“只做什么不做什么”在提示词中加入“不要做其他角色工作”的约束增加角色隔离Agent 开始修改需求范围PM 输出里包含太多模糊表述检查 PM 输出的功能优先级和验收标准是否可执行增加角色审批点让统筹者或人工确认需求范围调用成本远超预期每个角色都把所有原始上下文传给模型查看每个 Agent 的输入 token 数量优化get_visible_context()让每个角色只看必要字段增加上下文摘要Agent 陷入循环重试QA 发现问题后没有明确的“打回-修复”终止条件检查重试次数是否有上限设置最大重试次数重试达到上限后转人工处理API 调用报错模型名称或接口版本过旧查看错误信息中的 model 字段升级 SDK确认当前模型的 Chat Completions 调用参数这里特别提醒一个问题不要盲目让 QA 无限重试。在真实业务里Agent 生成质量波动是正常的但重试超过三次很可能只是浪费 Token并不会收敛到更优结果。更好的做法是设定“重试一次后必须合并人工建议”的熔断逻辑。9. 实际运营“一人公司”的工程建议跑通最小示例只是第一步。如果你想把这个五角色架构真正用在自己的项目里下面的建议值得认真参考。9.1 提示词要按“岗位说明书”来写给 Agent 写提示词不应该像写一句命令而应该像写岗位说明书。岗位说明书里要有角色定位核心职责输入信息输出格式禁止行为协作边界。例如 QA Agent 的提示词里应该写明“发现问题时指出打回哪个角色”而不是只说“检查质量”。只有这样后续的自动打回逻辑才能有依据。9.2 共享上下文是系统瓶颈需要定期压缩共享上下文里保存的内容越多后一个角色看到的信息越杂模型越容易丢失重点。建议每个角色写完产出后不要把原文无脑塞入共享上下文而是先做一次结构化压缩。比如 Engineer 的完整代码存入上下文时可以压缩成{ files: [main.py, models.py], key_functions: [create_todo, list_todo], dependencies: [fastapi, sqlalchemy], run_command: uvicorn main:app --reload }具体代码放进单独的文件或对象存储只有需要时再读取。9.3 一定要设置人工审批点五角色架构的真正主人仍然是人。特别是在以下场景里必须有人审批对外发布内容删除数据或执行破坏性操作涉及用户隐私信息需要支付费用的动作最终交付物进入生产环境。可以给 TeamContext 加一个approval_required字段当某个角色产出的内容触发审批条件时流程暂停并等待人工确认。这样做也会让你对 Agent 团队的实际能力边界保持清醒。9.4 用日志追踪每个 Agent 的决策过程多 Agent 系统很难调试的原因之一是“不可见”。你不知道某个角色是基于哪些输入做出决策的。因此生产环境必须记录每个 Agent 的实际输入 prompt输出结果token 消耗耗时上下游关系。这些日志不仅是排错工具也是优化提示词的数据来源。你在做版本迭代时可以对比不同提示词方案下 QA 通过率的变化。9.5 安全边界要提前划定第一不要在 prompt 中泄露敏感信息。Agent 输入内容可能会进入模型服务端涉及用户隐私时应做脱敏处理。第二Agent 生成的代码不能直接用于生产环境。当前模型的能力可以辅助生成代码但安全审计、依赖检查、权限校验仍然需要人工或专门工具完成。第三对 Agent 的文件操作和命令执行能力做最小化授权。即使你的 Agent 有调用 Shell 或读写文件的工具也应该限制在沙箱目录里。10. 总结与后续可以做的基础改造Hermes Agent Team 五角色架构的价值不在于它把五个 AI 角色起了几个好听的名字而在于它把“一个人做所有事”的隐性流程变成了可记录、可复制、可优化的显性流程。统筹拆解、需求细化、技术实现、运营包装、质量审查这五个节点覆盖了从想法到交付之间的主要环节也刚好是“一人公司”需要的完整能力闭环。如果你准备在自己的项目里落地这套模式建议从最基础的串行版本开始先跑通一个任务类型观察每个角色的实际输出质量。稳定之后再逐步加入以下改造给上下文增加自动摘要和压缩策略引入并行分支例如多个技术任务同时执行增加工具调用能力让 Engineer Agent 可以直接操作文件或执行测试命令建立提示词版本管理沉淀出最适合自己业务的五角色模板接入可观测性工具统计每个环节的耗时和成本。一个合适的实践起点是拿一个你最近两周内手动完成的重复性任务比如“写文章并排版”“生成项目计划并拆任务”把它替换成五角色流程跑一遍。对比一下你手动操作需要的时间、Agent 串行跑完需要的时间以及最终质量差距。你会发现真正值得优化的不是模型参数而是你和一个 AI 团队之间的协作方式。