之前我在个人博客里零零散散写过一些多智能体协作的尝试但真正把整套流程按“代理机构”的方式固定下来还是从这个叫“agency-agents”的项目开始的。它做的事情说起来并不复杂把一个项目从“客户一句话”到“成品交付”之间的所有环节拆成若干个由AI智能体承担的岗位让每个岗位按自己的职责处理信息、产出内容、提出意见再由一个统一的流程引擎把它们串起来。你可以把它当成一家没有工位的微型代理公司里面各角色各干各的活但协作结果最终会汇集到一组可以对外交付的文档。我做这个项目的直接动机是长期处理外包单时发现自己的时间大量浪费在重复沟通和修改上。客户提的需求经常只有三四句话但背后涉及的受众分析、竞品调研、核心卖点提炼、文案调性拿捏每一轮都要反复来回。这些事情并不是没有规律只是每次都要人肉重复一遍。我开始思考如果让一个需求分析师类型的智能体先把客户的话翻译成结构化任务书再让策划、文案、设计顾问、审核员这些不同角色的agent依次处理最后再经过人工抽检是不是就能把单次交付的准备时间从两小时压到半小时以内这个想法就是“agency-agents”的起点。这篇文章我会把项目的设计逻辑、角色定义、实际跑通的过程、遇到的主要问题以及我觉得值得继续做的方向全部展开。如果你是做服务外包的或者对多智能体协作感兴趣这里面的很多东西可以直接抄作业。1. 整体设计思路为什么一家“代理机构”需要一群agent1.1 传统工作流程里的隐性成本在哪里在正式写代码之前我花了一周时间做流程拆解。我把自己过去一年多接过的项目类型全部列出来发现大部分需求可以归类为品牌宣传文案、活动策划方案、社媒内容日历、简单视觉方向建议。这些项目的共同点是都需要几个固定的能力理解客户原始表达、补全背景信息、把信息组织成结构化的任务、在任务里拆解出多个产出方向、逐个方向写出可执行的文案、最后检查有没有偏离需求。如果靠人力来做每一步都需要沟通和确认尤其是需求理解和产出方向这两环占掉了几乎一半时间。而这两环恰恰又是最容易被规则化、模板化的客户说“我们想做一个年轻向的产品介绍页”其实背后就意味着受众画像、语气风格、文案结构、视觉偏好等一组默认参数。人工做的时候是凭经验快速脑补所以我希望agent也能做到这一点。1.2 把“外包协作”转译为“智能体协作”我更关键的一步是把现实中代理机构的协作模式翻译成技术架构。现实中有项目经理、策划、文案、美术指导、校对每个角色只负责自己那部分信息通过文档和会议传递。这个模式天然就适合用多智能体来模拟。在多智能体系统里每个agent可以有自己的系统提示词、自己的记忆区域、自己的输出协议。我让“需求分析师”只负责把原始需求转化成一个标准化的JSON任务书“策略策划”只阅读任务书并输出方向建议“文案执行”只接收策略并产出多个版本内容“视觉顾问”只负责给出风格和版式建议“质检员”则按规则逐项核对交付物。这样每个agent的输入输出都相当干净测试和排错也容易。注意刚开始我犯过一个错想设计一个“万能agent”来干所有事情。结果它总是把需求理解、文案、审核混在一起输出类型不可控后期根本无法追责。后来才彻底改成角色隔离的模式。1.3 项目的能力边界我需要提前说明“agency-agents”不做什么。第一它不做真实的图像生成视觉顾问只给方向和参考描述不直接产出图片第二它不替你做客户沟通所有agent的产出最后仍需人来看过、再转发给客户第三它不自动对接付款、合同这类业务流程只关注从需求到内容交付这一段。这个边界设定很重要因为如果你期望一个agent系统包揽所有事很容易在无关环节浪费精力。把边界划清楚后项目的目标就非常聚焦把从“原始需求”到“可交付内容”之间的处理流程尽可能自动化同时保留人工抽检和修改的入口。我觉得这是很多个人开发者容易忽略的一点不是所有环节都值得自动化先把高频、重复、低决策成本的部分自动化收益最大。2. 核心角色与信息流设计2.1 五个agent岗位和它们的职责协议我把团队里的角色固定为五个需求分析师、策略策划、文案执行、视觉顾问、质检员另外还有一个“流程控制器”负责调度但流程控制器不算内容角色。每个角色的职责用系统提示词约束得非常具体。比如需求分析师的唯一输出就是一张结构化的需求卡片包含项目类型、目标受众、核心关键词、必须包含的卖点、字数范围、语气风格、参考案例链接这些字段用JSON格式固化下来。视觉顾问的输出则是一段结构化的视觉建议包括主色建议、字体方向、构图参考、或参考文献格式的推荐而不会去写文案。每个agent都有各自的“工作守则”比如文案执行必须提供三个版本一个偏理性功能型、一个偏感性故事型、一个偏极简直接型。这三个版本不许合并再在这三版基础上生成一个推荐组合方案。质检员的协议里有一条硬规则如果发现文案里没有出现需求卡片中标记的“必含卖点”直接返回给文案执行重新写而不是自己动手修改。2.2 信息流的四个关键节点整个系统里的信息流其实不复杂但执行顺序和边界必须明确。我设置了四个关键节点需求解析、策略锚定、内容产出、质量验证。在需求解析节点流程控制器把客户原始消息直接交给需求分析师拿到结构化的需求卡片后进入下一环。策略锚定阶段由策略策划读取需求卡片输出三条方向策略每条方向包括目标解读、内容重心、情绪基调。内容产出阶段由文案执行读取需求卡片和策略锚定结果分别按不同策略生成文案。质量验证阶段由质检员逐项核对需求卡片字段给出通过或不通过的结论以及需要修改的具体位置。这四个节点之间没有回头路但允许循环。如果质检不过需求卡片和当前文案会一并传回文案执行那里进行修改修改后再次进入质检最多循环两次。超过两次就自动通知人工介入。这个有限循环的设计防止了agent之间无限踢皮球。2.3 为什么不用单个大模型来包办可能有人会问把这些角色提示词合到一个prompt里让大模型一次输出完整方案不就行了吗我试过效果确实有但有一个致命问题一次输出时模型内部容易“偷懒”。比如需求分析不足就直接开始写文案或者文案写得天花乱坠却忽略了原始需求里的限制条件。把流程拆成多agent后每一环的上下文都相对简单模型不需要在同一个长上下文里来回切换角色输出的稳定性反而高很多。另外一个很重要的点是可追溯性。当单轮输出模式出问题时你很难判断到底是需求理解坏了还是文案生成坏了。但在多agent模式下我可以直接查看需求分析师抽出来的JSON卡片一眼就能判断是上游错了还是下游执行偏了。这种可追溯性对于工程调优来说是决定性的。3. 工程化实操从零搭起一套可复用的agent协作系统3.1 基础框架选择与安装在技术选型上我没有选择自己从零写调度逻辑而是基于一个开源的轻量级agent编排框架来做的具体名称在这里不展开但你可以在代码托管平台上搜“多智能体工作流编排”相关关键词找到同类项目。选择这个框架的原因有两点一是它已经实现了多agent之间的消息路由和上下文隔离二是它有可插拔的存储层可以方便地记录每个agent的输入输出轨迹。我推荐一个比较稳妥的起步组合后端用Python写编排框架用支持异步任务的模型接口统一走OpenAI兼容协议。这样即使你后续想换不同模型服务商也只需要改一个环境变量。我自己当时是接了一个支持较长上下文的商业模型接口同时在本地部署了一个较小的开源模型作为“快速预览”用这样可以控制成本。3.2 配置文件的写法与角色注册框架安装好之后最关键的一步是定义一个agents配置目录。我建议把所有角色定义放在一个yaml文件里而不是散布在代码中。这个yaml文件的每条记录包含三部分role角色名、system_prompt系统提示词、input_schema输入结构说明和output_schema输出结构说明。比如需求分析师的output_schema会定义所有字段的类型和必填项质量控制器的output_schema则包含一个布尔类型的pass字段和一个字符串类型的reason字段。这里贴一个简化版配置示例agents: - role: requirement_analyst system_prompt: | 你是一位资深的需求分析师。 你只把用户提供的原始需求整理成结构化需求卡片。 不要给出任何解决方案也不要写文案。 如果原始需求信息不足请在卡片中标记unknown字段。 input_schema: raw_text: string source_urls: list[string] output_schema: project_type: string target_audience: string key_points: list[string] mandatory_selling_points: list[string] word_count_range: [int, int] tone: string unknown_requirements: list[string]另一个需要特别配置的部分是角色之间的转发规则。在框架里每个agent都有一个“next”字段标明自己处理完后把结果传给哪个agent。比如需求分析师的next是strategy_plannerstrategy_planner的next是copywritercopywriter的next是quality_inspector。这个next规则不是写死在代码里的而是放在配置里方便后续随时修改流程顺序。3.3 工作流引擎中状态流转的实现框架本身提供了任务状态机的支持但我觉得默认状态不足以支撑业务情况所以做了一个简单的扩展。我为每个任务维护了当前阶段、输入内容、输出内容、重试次数、所有阶段的日志。流程控制器的核心逻辑其实只有几十行伪代码大致如下def run_workflow(task_id, raw_input): stage requirement_analysis result {} context {raw_input: raw_input} while stage ! done: agent get_agent(stage) response agent.execute(context) context[stage _output] response stage next_stage(stage, response) return context当然实际代码里我还加入了每次调用前的数据校验和调用后的输出schema校验。这一步非常重要因为模型偶尔会多输出字段或者漏字段如果不校验后面所有环节都会读到一个坏的上下文。我建议每个人都在agent调用后加一个简单的校验函数使用JSON schema库或自己写字段检查都行。3.4 如何保证上下文不串味多agent系统最怕的就是上下文污染前一个agent的错误判断或者跑题内容被后一个agent当作“事实”。为了防止串味我做了两个处理。第一每个agent的输入是固定的、显式命名的字段而不是前一环的完整输出。比如文案执行拿到的不是需求分析师的原始回复而是经过清洗后的需求卡片JSON。第二我在每个角色的系统提示词末尾都会加一句“你只应使用输入字段中的内容所有输出必须严格遵循当前角色职责不得引用你在其他角色中的猜测或假设。”这句话看着简单但实际测试中能显著降低跑题概率。我还额外做了一个“关键信息锁”需求卡片中的mandatory_selling_points字段在完整流程中不可被任何其他agent修改。框架会在每两个agent交接时检查这个字段是否仍存在且内容未被改动。这个锁让质检员有了一个固定的核对基准否则一个写文案的agent很容易在过程中“顺手优化”掉客户一开始强调的卖点导致交付结果大走样。4. 实战复盘从需求到方案完整走一遍4.1 输入一个典型的模糊需求为了验证系统我准备了一条过去经常遇到的客户需求“我们想做一个线上推广用的产品介绍长图主要面向二十多岁刚工作的人群突出产品省时省力最好有一种轻松的氛围文案不用太长但要有记忆点。”这条需求信息量其实很少没有账户名称、没有具体产品、没有投放渠道甚至没有说清楚“长图”是给视觉设计师用的画面描述脚本还是给文案用的排版文案。如果按照旧方式我需要先追问五个问题才能开始。现在我把这条需求放进“agency-agents”看它如何自动处理。4.2 各环节的实际输出观察需求分析师拿到这条消息后按协议生成了一张需求卡片。它抽取出的project_type是“social_media_image_script”target_audience是“23-29岁初入职场人群”key_points标记了“省时省力、轻松氛围、短文案、记忆点”。对缺失的账户和产品名它没有瞎编而是放到了unknown_requirements里并在后续传给策略策划时明确提示“账户信息和产品名称缺失策略中不输出具体品牌名”。这一步输出质量让我很满意因为如果换成单agent直接写文案它很可能会自动编一个品牌名或者顺着“省时省力”就开始写“一键搞定的神器”这种陈词滥调。现在的结构化过程天然逼迫它承认未知。策略策划拿到需求卡片后输出了三条方向策略。第一条是“效率提升型”突出下班时间解放用具体时间数据对比制造痛点第二条是“轻松生活型”用白描场景展示早晨从容的状态第三条是“反套路型”用一句自嘲的短句点出产品不可替代的价值视觉上可以采用手写字体。每条方向都配了执行要点和情绪基调。接下来文案执行分别按三条策略各写了两个版本其中方向二的一条输出是“早上比闹钟晚起二十分钟还能悠闲喝完一杯咖啡——这份从容是它给的。”这句话并不复杂但我看到时还是有点惊喜因为它直接呼应了“二十多岁刚工作”的生活场景而不是生硬的“高效”、“便携”等形容词堆叠。视觉顾问则基于这张长图的场景给出了主色建议暖白色配合低饱和橙色、字体方向正文用非衬线体标题可用手写感字体、构图建议上半部分文字区下半部分生活场景插画。质检员最后逐项核对了需求卡片。它发现整个交付内容缺少“记忆点”的显式解释于是返回给了文案执行。文案执行收到修改意见后在版本二里增加了一句“一句话总结它能替你把那些琐碎的小事悄悄打包带走。”重新提交后质检员才给出了pass。4.3 从输入到交付的耗时和成本统计我记录了一下这次完整运行的耗时模型调用一共11次从输入到最终质检完成用了大概90秒。由于大部分调用集中在文案和审核环节成本约为直接让模型写五版文案再人工整合的六成。最值得对比的地方是人工参与时间我只需要在质检通过后快速看一遍产出确认没有语法问题和明显品牌风险总共花了大约四分钟。而以前同样类型的基础策划我至少要花四十分钟以上。当然这个效率提升的前提是需求中的未知信息会被显式标记出来。如果unknown_requirements太多流程会直接停在一个需要人工补充信息的节点而不是继续硬跑。这也是我在流程控制器里特意加的一个分支如果unknown_requirements字段数量大于等于3自动进入“需人工确认”状态不再流转。5. 常见问题与调优经验5.1 最常见的五个协作卡死问题在测试阶段我遇到了不少“看起来像是死循环”的问题后来总结出五个典型情况。第一文案执行反复否定自己每次都给完全不同的方向导致质检永远不过。解决方法是给文案执行增加一个“创作纪律”先在内部草稿区列出三个方向的大纲再基于大纲写正文不许中途重写整段逻辑。第二需求分析师经常把“客户要求”和“自己的建议”混在一起导致后续每个环节都被带偏。解决方法是在输出schema里增加一个“建议与需求分离”字段把客户原话原样记录到original_statements里规则建议放到另一栏。第三视觉顾问和文案执行有时会互相“抄作业”视觉顾问写了一段文案方向文案执行又给了视觉建议。为了切断这种互相越界我在工作流里强制规定它们之间不直接通信所有信息都要通过策略锚定文档间接传递。第四质检员全凭模型主观判断标准不稳定。我后来把质检规则做成了可配置的checklist每个检查项单独打分低于某个阈值就不过。例如“核心卖点是否在文案中直接出现”、“语气是否符合需求卡片的tone字段”、“字数是否落在指定范围内”这三项是硬指标。第五模型返回的JSON偶尔会非法导致状态机崩溃。这个问题可以通过在每次调用后增加一个重试机制当解析失败时把错误信息回传给同一agent并强制要求修正输出格式而不是直接让整个流程失败。5.2 成本控制从Token浪费到精准调用多agent系统的成本其实很容易失控。最开始我把每个agent的上下文都设成无限长结果每次后续调用都要带上前面所有轮次的完整记录一次任务跑下来能耗费几万个Token。后来我做了两个优化。第一给每个agent限定一个max_context_tokens其中历史的“公共信息”只保留最近一次关键输出而不是所有输出。具体来说我的流程控制器维护了一个“摘要层”每当一个环节结束后会生成一份四到五句话的摘要后续agent只读摘要和当前阶段的结构化输出不读上一环的完整对白。第二针对文案生成这种高消耗环节我引入了“先生成大纲再扩写正文”的两步策略。文案执行首先只输出每个版本的要点和大纲经策略锚定文档确认后才针对被选中的大纲扩写完整文案。这个过程虽然增加了一次场景调用但因为即使被否掉其余大纲也不会扩充整体Token消耗反而下降了近三成。5.3 效果评估与后续扩展我对这套系统的效果评估不单看最终交付物过没过质检还会记录几个维度返工次数、未知需求数量、模型自我否定频率、平均单次任务成本。我给自己定了一个量化目标三个月内把平均返工次数从1.8降到0.7以下把单次简单需求的成本控制在普通模型直接生成方案的60%以下。目前来看这两项已经基本达成。下一步我想做几个方向的扩展一是增加一个“用户反馈学习层”把每次人工修改的内容记录下来定期生成一份修改流水线投喂给需求分析师的提示词让它慢慢熟悉自己常漏掉的点二是把多agent协作从“线性流水线”改成“多分支并行”例如在策略锚定阶段同时让两个不同风格偏好设定的agent输出策略最后由策略决策agent做选择。最后再分享一个实用技巧如果你也想尝试搭建类似的agent协作系统我强烈建议不要把第一步的目标设得太宏大。先拿一个你手头最熟悉的业务场景比如“写一次活动方案”或者“做一份演示文稿大纲”定义好三个角色就够需求整理、内容生成、质量检查。跑通一条极简流水线后续再慢慢加角色比如加一个“舆情分析”或者“竞争对手信息补充”。在这个过程中你会明显感受到每个新的agent不是让系统变复杂而是让每个环节的“人设”更清晰、更不会越界。另一个从实际中得来的经验是每次运行完记得把关键日志导成文本文件存起来。这个习惯对排查问题帮助极大。当某个agent连续三次都给出了重复内容或者自我否定时日志里的温度、概率值、提示词版本都会成为定位问题的重要线索。我自己的做法是把每一次运行的prompt、输出、校验结果都按日期存进一个单独的目录丢不了也方便回放。这个习惯让“调优”这个听起来很虚的词变成了每天晚上都能做的具体事情。