企业官网建设流程全解析

最近一直在折腾一个很有意思的项目方向——agency-agents。坦白说，第一次看到这个命名的时候，我脑子里浮现的是那种传统广告公司里的创意总监、文案、美术指导各司其职的画面，跟AI好像没什么关系。但等到我把手头的实验做下来，才发现这个命名太精准了：它本质上是让一群大模型Agent按照现代公司或代理机构的组织方式协作，有分工、有汇报关系、有质检环节，最终产出比单个Agent可靠得多的结果。如果你最近也关注“agents”或者刷到过“agents anywhere”这类热词，应该能感觉到，现在的智能体早就不是那个“你问我答”的聊天机器人了，而是一套可以编排、可以复用、可以嵌入任何业务流程的“虚拟员工团队”。

这篇文章我不想讲空泛的概念，而是直接以agency-agents为核心，拆解这类“机构化多智能体系统”从设计思路到落地实现的完整过程。里面会聊到：为什么要用“机构”而不是“单体”来组织Agent、角色设计与协作协议怎么定、基于LangGraph的编排实现方案、实测踩过的坑，以及如何把同一套Agent机构部署到不同场景中。读者对象是有一定Python基础、想自己搭建多智能体应用或做AI产品原型的人。0基础的朋友也完全可以看，我会用大量类比把底层逻辑讲清楚。

1. 先把名字拆明白：agency-agents到底在做什么

1.1 “拆开做”永远比“一个人扛”更稳

我先说结论：大多数情况下，一个超级全能的Agent解决不了复杂问题，但一群各有边界的Agent协作，反而能交出更高质量的结果。agency-agents这个名字的核心含义，就是把一群大模型Agent编排成一个“代理机构”，在这个机构里，每个Agent都有明确的职位（role）、清晰的职责边界（scope）和固定的产出格式（output schema），它们之间通过有序的协作流程完成一个统一目标。

为什么这么做？我举个特别日常的例子。假设让你一个人负责一次完整的市场推广，从市场调研、策略制定、创意脑暴、文案撰写到视觉方案审核，全流程一个人做，大概率会出现两个问题：一个是越往后越累，质量和初稿明显下滑；另一个是你很难发现自己的盲区，因为没有人从第三方视角给你的产出挑毛病。但如果把任务拆给“调研专员”“策略总监”“创意文案”“视觉审校”四个人，每个人只干自己最擅长的那一环，并且下一环会对上一环的产出进行检查和反馈，最终结果会稳健很多。

agency-agents就是把这个模式复制到了大模型应用层。一个单体Agent要同时处理调研、规划、写作、审核这些动作时，不仅会面临长上下文下的注意力衰减，还容易出现“既要又要”导致的风格漂移。而多Agent编排能让每个角色只维护一小段上下文，专注单一职责，整体系统因此获得三个显著优势：

1. 可靠性提升：每个Agent只处理所属领域的一小块内容，指令遵循度明显更高。
2. 过程可观测：每个节点都有清晰的输入输出，业务方可以查看中间结果，而不是面对一个“黑盒"。
3. 独立迭代：某个角色效果不好，单独调它的Prompt和行为参数即可，不会影响其他角色。

1.2 从单体Agent到Agent机构：一次分工革命

传统的单Agent应用，本质上是一个“问答型”结构：用户输入问题，Agent内部自行完成理解、规划、检索、生成，最后返回一段答案。这个过程对用户来说像黑盒，而且一旦任务复杂到一定程度，单Agent自身的规划能力会迅速见底。

机构化多Agent系统则不同，它引入了“业务流水线”的思想。我一般把常见的组织模式分成三类，理解了这三类，你就能明白agency-agents所处的位置和它擅长什么：

agency-agents最吸引我的地方在于它引入了“质检-修订”闭环。真实公司里，部门提交的成果不可能直接对外发布，一定得有主管审、客户看、返工修订等环节。而在大多数开源的多Agent框架里，Agent们把产出往共享上下文里一丢就算完事，质量没人把关。agency-agents强调把“评审者（Critic）”当作与“执行者（Executor）”平级的一等公民，流程会因为评审打分不合格而触发修订循环。

这种机制带来的直接好处是：最终交付物的质量下限被拉高了。哪怕Executors偶尔发挥失常，Critic也能拦下一部分不合格结果，而不是让糟糕的产物直接流到用户面前。

2. 搭建一套“代理人团队”的核心设计决策

2.1 角色设计：不要只写“你是AI助手”

搭建agency-agents的第一步不是写代码，而是定义角色。很多人在这一步偷懒，在System Prompt里写一句“你是一个有用的AI助手”就完事，然后发现后期Agent的行为完全不受控。我自己的经验是，每个Agent都必须有一份“岗位说明书”，里面至少要包含五个要素：

• 专业背景：告诉模型它是什么身份，最好控制在50字以内，比如“你是拥有10年经验的资深市场研究员”。
• 职责边界：明确它负责什么、不负责什么。例如“你只负责信息搜集与结构化整理，不给出营销建议”。
• 输入说明：它从上游接收什么格式的数据。
• 输出格式：强制的JSON或Markdown结构，这一步会直接影响下游能否正常解析。
• 质量要求：什么样的产出算合格，比如“结论必须有数据或引用支撑，严禁编造”。

我最初做角色Prompt时走过一个弯路：把质量要求写得特别长，结果模型反而抓不住重点，产出变得束手束脚。后来我学到的经验是：质量要求最好拆成“必备项”和“加分项”两组，必备项控制在三条以内，且写成可客观判断的句式，比如“结果中每条结论必须附数据来源”，而不是“结果要尽量准确”。后者模棱两可，模型根本无法执行。

另外，角色之间一定要做“职责隔离”。我见过很多人设计多Agent系统时，每个Agent的Prompt里都带着完整任务上下文，结果就是三个Agent的产出思路几乎一模一样——因为它们都在同一个知识背景下“自由发挥”。正确的做法是：给每个角色只提供它完成本职工作所需的上下文片段，同时明确指定“你只能基于上游输入输出，不要自行补充你没有获得的信息”。

2.2 通信与协作机制：共享黑板还是定向收发

角色定义清楚之后，下一个要解决的问题是Agent之间怎么“说话”。目前主流方案大致可以分为两种：共享黑板模式和定向消息传递模式。

共享黑板模式，适合类似于开会时有个公共白板，所有Agent都能往上写。但问题是，一旦某个Agent写入了错误信息，后续所有Agent都会读到错误信息。语境里它还可能造成“上下文污染”——下游Agent面对大量无关信息时，注意力会被严重干扰。

定向消息传递模式，适合上下级或上下游之间一对一传递。Agent A的输出直接进入Agent B的输入槽位，B只看到A给自己的东西。这种模式上下文更干净，但实现起来需要显式定义每条通信链路的格式和协议，灵活性稍差。

我在agency-agents实现中采用的是一种混合方案：底层用共享状态池，但为每个Agent定义了严格的白名单视图。也就是说，所有节点在技术上共用同一个State对象，但每个Agent读取State时，代码只把该角色需要的字段传给LLM。例如researcher节点只读取task_plan字段并输出research_findings字段，它既看不到也改不了draft_content。这种做法既保留了共享状态在编排上的便捷性，又避免了上下文污染的风险。

2.3 框架选型：为什么用LangGraph而不是自研状态机

理论上这种多Agent编排完全可以自己写，用Redis或者SQLite存状态，再写几个轮询函数把不同模型串起来。但我不建议这么干，尤其是项目还在快速迭代阶段的时候。自研的状态机框架往往要处理大量边缘情况：节点重试、异常恢复、状态快照、可视化调试，全部自己实现的话工作量非常大，而且很容易因为某个非核心代码写得粗糙，导致整体流程不稳定。

我最终选了LangGraph，理由很直接：

1. 图执行引擎本身包含了状态管理：LangGraph天然支持节点与边的建模，节点是Agent逻辑，边是路由和条件流转，状态通过StateGraph统一管理，而且支持每一步的Checkpoint持久化。
2. 断点续跑能力极强：调试时可以从任意节点恢复执行，直接跳过前面昂贵的LLM调用。
3. 可视化调试：配合LangSmith或LangGraph Studio，可以直接观察每个节点的输入输出，这种透明感在调多Agent系统时真的太重要了。

当然，如果你熟悉CrewAI，那个框架上手更快，角色协作的抽象层也更友好，适合快速原型验证。但CrewAI把很多流程细节都藏起来了，比如显式控制路由条件时反而要绕一些弯路；AutoGen则更偏向对话式多Agent交互，适合“Agent群聊”场景，但流程的确定性和可控性不如LangGraph。如果你追求的是业务流程级的稳定性，我建议还是在LangGraph上花时间。

3. 手把手实现一个agency-agents编排系统

3.1 环境准备与项目结构

下面我们进入实操环节。我以Python环境为例，先安装依赖：

python -m venv .venv source .venv/bin/activate # Windows下执行 .venv\Scripts\activate pip install langgraph langchain-openai python-dotenv

如果你使用的不是OpenAI官方接口，或者想用DeepSeek、Qwen、本地Ollama等模型，只要接口兼容OpenAI的Chat Completions格式，通过langchain-openai里的ChatOpenAI(base_url=...)都能接上。我测试时用的是base_url指向本地代理服务的OpenAI兼容接口，代码里只需改环境变量模型名指向即可适配不同后端。

项目的目录结构这样组织：

agency_agency/ ├── agent_agency/ │ ├── __init__.py │ ├── state.py # 定义全局状态结构 │ ├── nodes/ │ │ ├── __init__.py │ │ ├── planner.py │ │ ├── researcher.py │ │ ├── drafter.py │ │ ├── critic.py │ │ └── editor.py │ ├── workflows/ │ │ └── build_graph.py │ └── config.py # 模型配置与全局参数 ├── .env └── main.py

对应的.env文件：

OPENAI_API_KEY=sk-xxx OPENAI_API_BASE=https://api.example.com/v1 # 根据实际模型服务商配置 MODEL_NAME=gpt-4o-mini

提示：如果模型服务商只提供OpenAI官方API，那么OPENAI_API_BASE不用填写，MODEL_NAME填具体的官方模型名即可。强烈建议把模型名做成配置项，因为同一个Agent机构在联调阶段和服务化阶段，很可能要切换不同档位的模型。

3.2 核心代码：从状态定义到Planner与Researcher

先定义全局状态。这一步是整个系统的“协议层”，所有节点都要严格遵守：

# state.py from typing import TypedDict, List class AgentState(TypedDict): task: str # 用户提交的原始任务 task_plan: str # Planner输出的工作计划 research_findings: str # Researcher输出的调研结论 draft_content: str # Drafter输出的初稿 critique_feedback: str # Critic输出的评审意见 critique_score: float # Critic给出的分数 revised_content: str # Editor输出的终稿 iteration_count: int # 修订轮数

注意到我特意加了iteration_count字段，这个字段在后面的防死循环逻辑里非常关键。如果某个任务质量迟迟不达标，系统应该有终止机制，而不是让Critic和Editor无限循环下去。

然后写Planner节点。Planner的职责是把一个模糊的原始任务拆解成清晰的执行计划：

# nodes/planner.py from langchain_openai import ChatOpenAI from agent_agency.state import AgentState PLANNER_PROMPT = """你是某咨询公司的项目规划总监。 你接收客户的任务描述，负责将任务拆解为可执行的分阶段计划。 输入： - 客户任务: {task} 工作原则： 1. 只输出计划，不执行计划中的任何具体工作。 2. 计划中每一步必须有明确目标、参与角色、预期产出。 输出格式（JSON）： {{ "overview": "对任务的简要理解", "steps": [ {{"step": 1, "action": "具体动作", "owner": "负责角色", "deliverable": "产出物"}} ] }} 请直接输出JSON，不要有多余说明。""" def planner_node(state: AgentState) -> dict: llm = ChatOpenAI(model=state.get("model_name", "gpt-4o-mini")) prompt = PLANNER_PROMPT.format(task=state["task"]) response = llm.invoke(prompt) return {"task_plan": response.content}

说实话，这段代码在生产环境里还需要再加工一步——用response_models做结构化输出或者至少做一次JSON解析与异常捕获。但作为项目起步，让模型以JSON格式生成并由下游做容错处理，已经是够用的方案。关键在于Planner的明确边界：“只拆解，不执行”。只要这个边界守住，下游的Researcher就不会因为上游丢来一篇长篇大论而无所适从。

接下来是Researcher节点。它的输入是Planner生成的task_plan，输出是结构化的调研发现：

# nodes/researcher.py RESEARCHER_PROMPT = """你是某咨询公司的资深行业研究员。 你只负责根据执行计划中的信息收集部分执行调研，不撰写最终方案。 上游计划: {plan} 要求： 1. 只输出与上游计划直接相关的调查结果。 2. 每条结论后尽量注明信息来源类型（数据报表/公开资料/经验判断）。 3. 尽量客观，不做主观建议。 输出格式（JSON）： {{ "findings": ["结论1", "结论2", "..."], "risks": ["风险点1", "风险点2"] }} 请直接输出JSON。""" def researcher_node(state: AgentState) -> dict: llm = ChatOpenAI(model=state.get("model_name", "gpt-4o-mini")) prompt = RESEARCHER_PROMPT.format(plan=state["task_plan"]) response = llm.invoke(prompt) return {"research_findings": response.content}

这里有一个我反复强调过的细节：researcher_node在读取状态时，只使用了task_plan字段，没有把原始task也塞进去。这么做是有意的。调研人员只需要知道自己要调研什么，不需要反复揣摩客户原始的模糊需求，否则它的输出很容易被“客户的意图”带偏，写出大量推测性内容而不是客观调研结果。

3.3 加入Drafter、Critic与Editor，形成质检回路

流水线走到这里，已经有了计划和调研结果，接下来让Drafter产出一份完整初稿。这个节点的工作相对简单，把task_plan和research_findings合起来写一篇结构完整的内容：

# nodes/drafter.py DRAFTER_PROMPT = """你是某策划公司的资深内容策划。 根据调研结果和计划撰写一份可交付初稿。 计划：{plan} 调研结果：{research} 要求： 1. 遵循调研结论，不要新增未经验证的信息。 2. 内容结构清晰，分章节呈现。 3. 初稿完整可读，长度控制在1500字以内。 输出：直接输出正文内容。""" def drafter_node(state: AgentState) -> dict: llm = ChatOpenAI(model=state.get("model_name", "gpt-4o-mini")) prompt = DRAFTER_PROMPT.format( plan=state["task_plan"], research=state["research_findings"] ) response = llm.invoke(prompt) return {"draft_content": response.content}

真正体现agency-agents灵魂的，是Critic和Editor这两个角色构成的质检闭环。

Critic负责给初稿打分并给出具体的修改意见。打分标准我建议做成一个显式的评分卡，模型更容易对齐：

# nodes/critic.py CRITIC_PROMPT = """你是某代理机构的首席质量官。 你的职责是严格审查交付物质量，给出客观评分与修改意见。 待审内容：{draft} 评审标准（满分100分）： - 信息准确性（0-40分）：内容有无虚构事实？是否忠于调研结果？ - 结构清晰度（0-30分）：逻辑层次是否分明，是否便于阅读？ - 行动价值（0-30分）：内容是否能直接指导后续行动？ 输出格式（JSON）： {{ "score": 85, "feedback": "具体的修改意见，逐条说明，禁止空泛评价。" }} 请直接输出JSON。""" def critic_node(state: AgentState) -> dict: llm = ChatOpenAI(model=state.get("model_name", "gpt-4o-mini")) prompt = CRITIC_PROMPT.format(draft=state["draft_content"]) response = llm.invoke(prompt) # 实际项目中这里要将response.content解析为dict，拿到score和feedback # 简单起见，这里直接把原始文本存在feedback字段 return {"critique_feedback": response.content, "critique_score": 80}

这里有个很实际的点：评分与意见必须来自同一个模型实例，否则你很难解释“某个Agent给了80分，另一个却给了95分”到底差在哪。让Critic自己独立打分，而不是和其他Agent共享判断标准，虽然会有一定主观性，但在流程可控性上是更稳妥的做法。

Editor收到评审意见后对初稿进行修订：

# nodes/editor.py EDITOR_PROMPT = """你是某策划公司的执行编辑。 根据评审意见修订初稿，输出修改后的最终版本。 原始初稿： {draft} 评审意见： {feedback} 要求： 1. 逐条回应评审意见，不得遗漏。 2. 保持整体内容风格一致，不要推倒重写。 3. 只输出修订后的完整文稿。""" def editor_node(state: AgentState) -> dict: llm = ChatOpenAI(model=state.get("model_name", "gpt-4o-mini")) prompt = EDITOR_PROMPT.format( draft=state["draft_content"], feedback=state["critique_feedback"] ) response = llm.invoke(prompt) return {"revised_content": response.content}

现在关键问题来了：流程怎么决定“是通过评审，还是回去再改一版”？这就要用到LangGraph的条件边了。

3.4 用LangGraph把“评审-修订”循环串起来

构建图的核心代码如下：

# workflows/build_graph.py from langgraph.graph import StateGraph, START, END from agent_agency.nodes.planner import planner_node from agent_agency.nodes.researcher import researcher_node from agent_agency.nodes.drafter import drafter_node from agent_agency.nodes.critic import critic_node from agent_agency.nodes.editor import editor_node from agent_agency.state import AgentState def should_continue(state: AgentState) -> str: # 从Critic的原始内容里解析出分数，这里简化处理： # 实际工程中以结构化解析的critique_score为准 score = state.get("critique_score", 0) if score >= 90 or state["iteration_count"] >= 3: return "accept" return "revise" workflow = StateGraph(AgentState) workflow.add_node("planner", planner_node) workflow.add_node("researcher", researcher_node) workflow.add_node("drafter", drafter_node) workflow.add_node("critic", critic_node) workflow.add_node("editor", editor_node) workflow.add_edge(START, "planner") workflow.add_edge("planner", "researcher") workflow.add_edge("researcher", "drafter") workflow.add_edge("drafter", "critic") workflow.add_edge("editor", "critic") # 修订后再次评审 workflow.add_conditional_edges( "critic", should_continue, { "accept": END, "revise": "editor" } ) app = workflow.compile()

这段图的核心逻辑并不复杂：计划→调研→初稿→评审。评审通过，结束；评审不通过，交给Editor修订，然后回到Critic再评。iteration_count在Editor节点里自增，当超过最大轮数时，即使分数不达标也强制结束，避免死循环。

用iteration_count强制兜底的经验，是我在真实项目中摔出来的教训。第一版实现里我没加轮数限制，结果因为Critic的Prompt写得过于严苛，模型永远在挑毛病，Editor也确实在每一轮都有微小改动，系统跑了二十分钟还在循环。加了“最多修订三版”的限制之后，系统行为立刻变得可预期了。

主流程入口很简单：

# main.py from agent_agency.state import AgentState from agent_agency.workflows.build_graph import app def run_agency(task: str) -> dict: initial_state: AgentState = { "task": task, "task_plan": "", "research_findings": "", "draft_content": "", "critique_feedback": "", "critique_score": 0.0, "revised_content": "", "iteration_count": 0, } result = app.invoke(initial_state) return result if __name__ == "__main__": result = run_agency("写一份智能客服产品的市场进入方案，重点面向电商行业") print(result["revised_content"])

跑完这个过程，你会在result里拿到终稿，同时还能拿到全程的计划、调研结论和每一轮的评审意见。这些中间产物如果你愿意，完全可以再交给一个人工审核台做二次确认——这正是agency-agents这类系统最大的魅力：它不是替你拍板，而是把“决策所需的前置材料”全部给你准备好。

4. 规避“智能体失控”的实战经验

4.1 典型问题一：Agent陷入了无限循环

这是多Agent系统最容易出现的问题，而且出事的时候很隐蔽。表面看每个节点都在正常工作，实际整个图已经在一个局部回路里空转了十几轮。我遇到过三种典型情况：

• Critic阈值设置过高：初稿质量明明已经可以，评分却一直低于阈值，导致Editor一直改稿。
• Critic与Editor在“互相抬杠”：Critic每次提修改意见，Editor照着改了之后，Critic不认账，又换一个角度提意见。
• 路由函数逻辑错误：条件边写反了，该走END的时候走了revise。

排查手段也不复杂。使用LangGraph的Checkpoint机制，在should_continue函数里打印当前评分与轮次，基本上三轮之内就能确认问题在哪。如果Critic完全没有给出合理反馈，就去检查Critic的Prompt是不是使用了“永远不满意”风格的话术，比如“请尽量改进所有细节”这类写法。

注意：我给Agent机构的每个闭环回路都设计了“最大轮次”和“最低接受分”双重保险。最大轮次保证任何情况下系统都能终止，最低接受分保证质量底线。只有双重保险同时存在，你才敢放心地把这个系统交给业务方使用。

4.2 典型问题二：上下文互相污染

我在2.2里提过共享状态池的隐患。这里详细展开一下。第一版agency-agents里，我给所有节点传了整个AgentState的完整转储，结果出现了一个特别尴尬的现象：Editor生成的内容不断向Critic的偏好“看齐”，因为Critic的历史评审意见一直躺在上下文里，Editor模型“学”到了这个偏好，越改越像在讨好Critic，而不是改进内容本身。

这个问题本质上是并行Agent系统中最经典的“信息泄漏”问题。我后来为每个节点写了一个build_node_context(state, fields)辅助函数，只抽取角色所需的字段：

def build_node_context(state: AgentState, fields: list[str]) -> AgentState: return {field: state[field] for field in fields}

每次组装Prompt时，只引用这个裁剪后的上下文。比如Critic只给draft_content，Editor给draft_content和critique_feedback，Planner只给task。这套约束看似多此一举，但它确实是我在项目调试中收益最大的一个改动。

4.3 典型问题三：多Agent输出“假协作”

还有一种情况也很常见——几个Agent输出的内容高度相似，看起来像商量过一样。这通常有三个原因：

1. System Prompt过于宽泛：每个Agent被赋予的职责不够具体，以至于它们都在“基于通用常识完成任务”。
2. 共享上下文过强：所有Agent都读到了同一份调研资料，失去独立视角。
3. 模型跟随倾向：在缺乏明确差异化要求的Prompt中，大模型倾向于输出最大化“一致性”的结果，而不是“差异性”。

我的解决办法是：在角色Prompt中强制加入“视角声明”。比如Researcher必须标注“我关注数据与事实风险”，Drafter必须标注“我关注可读性与说服力”，Critic必须标注“我关注逻辑漏洞与信息失真”。当每个角色被给定不同视角后，产出的差异性立刻打开了。

还有一个经验：不要给多个Agent设置相同的temperature。并行开展创意类的Agent，可以把温度调到0.8以上；评审类、数据加工类的Agent温度尽量贴近0。让“发散型角色”发散，“收敛型角色”收敛，整个系统的行为才会像一支真正的团队，而不是一群复读机。

5. 把同一个Agent机构部署到任何场景

5.1 agents anywhere的三种落地形态

agency-agents项目做完之后，最自然的疑问是：这套东西除了在命令行里跑通，还能用在哪里？热词“agents anywhere”其实点出的正是这个问题——Agent编排能力只有嵌入到真实场景中才具有生产力。我自己至少用过三种部署形态：

第一种：本地CLI工具

就像上面的main.py一样，把整个编排流程封装成一个命令行入口，支持传入任务描述和导出路径。这种形态最适合个人知识工作者。比如我写行业分析报告前，先给这个CLI一个主题，它自动跑完调研、初稿、评审、修订，输出的终稿我再人工润色后直接使用。优点是零成本、隐私可控；缺点是只能服务于一台机器。

第二种：HTTP API服务

把run_agency函数封装成FastAPI接口，其他业务系统通过HTTP调用。这种形态适合嵌入到公司的内容生产流程里，比如工单系统接到新需求时自动触发一套策划流程。封装的关键点在于把长耗时任务设计成异步模式：提交任务时返回task_id，处理完成后通过回调或主动查询拿到结果。不建议直接用同步HTTP请求去等待一个需要多次LLM调用、耗时几十秒的编排过程。

第三种：消息平台自动回复助手

更进一步，可以把这套Agent机构接到IM机器人框架上。用户是通过类似业务群里发一条需求消息来触发任务，系统以Agent机构名义在群内自动回复初稿、评审摘要和终稿。这个形态对流程稳定性要求更高，因为一旦出React死循环，用户看到的是机器人无限“刷屏”输出。我建议在这种形态下，强制在路由边界上加上“人工审批节点”逻辑——所有最终输出必须先进入待确认队列，由管理员一键放行后才对外发送。

5.2 一次构建、多处复用的关键注意点

适配不同场景时，有几点是我反复提醒自己的：

• 模型接入层必须配置化。不要在生产代码里硬编码具体模型名。一个Agent机构里可以给不同角色配置不同档位的模型——Planner和Critic用更强的模型，Researcher和Editor用性价比模型，整体Token成本能下降40%还不损失质量。
• 角色职责与具体业务解耦。我一开始把电商营销知识写进了Researcher的Prompt，后来发现换个行业就完全不适用。正确做法是让Researcher保持“通用调研者”身份，行业背景知识通过额外的知识库检索工具注入，而不是写死在角色人格里。
• 流程状态要有命名空间。如果多个场景共用同一个状态库，不同任务的task_id之间要隔离干净。否则一旦某个场景的任务上下文串到另一个场景，你的调试难度会翻好几倍。

以我个人经验看，把agency-agents从“代码仓库里的玩具”变成“真正有价值的生产工具”，核心不在于把Agent的Prompt调得多完美，而在于把流程边界、角色边界、状态边界三者都画清楚。边界清楚了，再复杂的智能体协作都不会乱；边界模糊，哪怕只有一个Agent，也会翻车。

最后再分享一个我调试这类系统的小技巧：每次跑完app.invoke()后，顺手把完整的result状态对象序列化存一份。不要小看这个动作，多Agent系统的每次执行都非常昂贵，而且充满了非线性。等出了问题再回头查，没有这份存档，你连“是哪一轮评审把方向带偏了”都定位不出来。存了之后，把每个状态的变更增量对比一下，大部分疑难杂症都能在一杯咖啡的时间内找到原因。