![]()
所有完整内容，首发于公众号『技术老金』及个人博客，欢迎关注交流
老金导读：
你是否发现，为了让AI完成一个复杂任务，你的提示词（Prompt）正变得越来越长、越来越臃肿？你试图将一个研究员、一个程序员、一个测试员的职责，全部塞给同一个AI，期望它成为一个"全能超人"。
但结果往往是：AI"精神错乱"，输出质量忽高忽低，成本飙升，且一旦出错，调试如同噩梦。
这条路走不通。
专业的玩家，会像一个真正的架构师一样思考：我们需要的不是一个"超级个体"，而是一支"精英团队"。
这，就是"多智能体（Multi-Agent）系统"的魅力。本文将手把手带你，用当今最强大的流程编排工具LangGraph，构建一个由"研究员-写手-评审员"组成的内容创作AI团队。你将掌握让AI互相协作、审查、甚至循环修改工作的核心技术。
这篇文章是独立的、端到端的实战教程。 如果你对LangGraph还完全陌生，可以先阅读我们的《LangGraph入门与避坑指南》作为预习，那会让你更容易上手。
一、为什么需要"AI团队"，而不是一个"全能AI"？
我们很容易陷入一个误区：期望用一个"超级提示词"让一个AI模型解决所有问题。但在真实、复杂的业务场景中，这几乎行不通。原因有三：
- 职责不清（Responsibility Confusion）： 一个冗长的、包含多种任务指令的Prompt，很容易让LLM"精神错乱"，顾此失彼，导致输出质量严重下降。
- 成本高昂（High Cost）： 复杂的任务链往往需要最强大的模型（如GPT-4o）来处理，如果每一步都用它，成本会非常高。而实际上，某些环节（如格式整理、意图识别）用更便宜的模型就足够了。
- 难以维护（Hard to Maintain）： "超级提示词"是一个巨大的黑盒，一旦某个环节出了问题，调试和迭代的难度极高，牵一发而动全身。
而多智能体系统，就像一个分工明确的人类团队，每个Agent都有单一、清晰的职责。这让我们的系统更清晰、更健壮、也更经济。
二、实战：构建一个"内容创作AI团队"
我们将构建一个由三位AI专家组成的团队：
- 研究员（Researcher）: 负责根据主题，上网搜索、整理资料。
- 写手（Writer）: 负责根据研究员的资料，撰写初稿。
- 评审员（Reviewer）: 负责审查初稿，提出修改意见，并决定是通过还是打回重写。
这个流程中，最关键的是"评审员"可以决定工作流的走向，如果他不满意，可以将任务"打回"给写手，形成一个循环（Loop）。这正是LangGraph的威力所在。
下面，我们来看代码如何实现。
第一步：定义团队的"共享工作台" (TeamState)
State是LangGraph的灵魂，它是所有智能体共享信息的地方，就像团队的中央白板。
from typing import TypedDict, Annotated
class TeamState(TypedDict):
topic: str # 任务主题
research_material: Annotated[str, "研究员收集的资料"]
draft: Annotated[str, "写手撰写的初稿"]
review_feedback: Annotated[str, "评审员的反馈意见"]
revision_count: int # 修订次数，防止无限循环
final_report: Annotated[str, "最终报告"]
我们定义了一个TeamState，包含了任务流转中所有需要的数据。Annotated可以让我们为每个字段添加描述，增加可读性。
第二步：创建"专家"节点 (Agent Nodes)
每个Agent都是一个Python函数，它接收当前的State作为输入，并返回一个包含更新后数据的字典。
1. 研究员 (Researcher): 它需要一个工具来上网搜索。这里我们用DuckDuckGoSearchRun。
from langchain_community.tools import DuckDuckGoSearchRun
search_tool = DuckDuckGoSearchRun()
def researcher_node(state: TeamState):
print("--- 节点: 研究员 ---")
topic = state["topic"]
research_material = search_tool.run(f"深入研究主题: {topic}")
return {"research_material": research_material}
2. 写手 (Writer): 它接收research_material，并调用LLM撰写初稿。如果review_feedback存在，它会一并纳入考虑进行修改。
def writer_node(state: TeamState):
print("--- 节点: 写手 ---")
# ... (构建prompt) ...
llm = ChatOpenAI(model="gpt-4o", temperature=0.7)
draft = llm.invoke(prompt).content
# 更新修订次数
revision_count = state["revision_count"] + 1
return {"draft": draft, "revision_count": revision_count}
3. 评审员 (Reviewer): 这是最关键的决策节点。为了让LLM给出非黑即白的判断，我们使用了Function Calling 。我们定义一个ReviewDecision模型，强制LLM必须决定"通过"或"需要修改"。
from langchain_core.pydantic_v1 import BaseModel, Field
class ReviewDecision(BaseModel):
"""评审决定"""
decision: str = Field(description="只能是 '通过' 或 '需要修改'")
feedback: str = Field(description="如果'需要修改', 请提供修改意见。")
def reviewer_node(state: TeamState):
print("--- 节点: 评审员 ---")
# ... (构建prompt) ...
llm_with_tools = ChatOpenAI(model="gpt-4o").bind_tools([ReviewDecision])
response = llm_with_tools.invoke(prompt)
tool_call = response.tool_calls[0]
decision_data = tool_call['args']
if decision_data['decision'] == '需要修改':
return {"review_feedback": decision_data['feedback']}
else:
return {"review_feedback": "", "final_report": state["draft"]}
第三步：定义"工作流" (Conditional Edges)
这是LangGraph的精髓所在，它决定了团队的协作规则。
def should_continue(state: TeamState):
print("--- 条件判断 ---")
# 如果达到最大修订次数，或评审员没有给出反馈，则结束
if state["revision_count"] > 3 or not state.get("review_feedback"):
return END
else:
# 否则，打回给写手
return "writer"
# ... 在Graph构建中 ...
graph.add_conditional_edges(
"reviewer", # 在这个节点之后进行判断
should_continue, # 使用这个函数来决策
{
"writer": "writer", # 如果返回"writer"，则下一个节点是writer
END: END # 如果返回END，则流程结束
}
)
add_conditional_edges方法让我们的Graph具备了"思考"能力。它在reviewer节点执行完毕后，调用should_continue函数，根据函数的返回值（"writer"或END）来决定下一个节点的走向，从而完美地实现了循环修改的业务逻辑。
第四步：组装与运行
最后，我们将所有节点和边组装起来，编译成一个可执行的app。
from langgraph.graph import StateGraph, END
graph = StateGraph(TeamState)
# 添加节点
graph.add_node("researcher", researcher_node)
# ... (添加writer, reviewer)
# 设置入口和常规边
graph.set_entry_point("researcher")
graph.add_edge("researcher", "writer")
graph.add_edge("writer", "reviewer")
# 添加条件边 (如上所示)
# 编译
app = graph.compile()
# 运行
topic = "LangGraph相比于CrewAI的优势是什么？"
initial_state = {"topic": topic, "revision_count": 0}
for s in app.stream(initial_state):
print(s)
当你运行这段代码时，你会清晰地看到三个智能体如何依次被调用，评审员如何做出判断，以及在报告被打回后，流程如何自动地回到写手节点，开始新一轮的修改。
老金总结
今天，我们从一个"线性流程"迈向了一个"协作团队"。通过LangGraph，我们不仅能定义任务的顺序，更能注入判断、循环、协作等复杂的业务逻辑。
这套"研究员-写手-评审员"的模式，几乎可以平移到任何需要"生成-审核"机制的场景中，例如：
- 代码生成与测试：
程序员Agent写代码，测试员Agent跑测试，不通过就打回。
- 营销文案与合规：
文案Agent生成广告词，法务Agent进行合规审查。
- 数据分析与洞察：
分析师Agent跑数据，策略师Agent从报告中提炼商业洞察。
掌握了多智能体系统的构建，你就真正拥有了用AI解决复杂、真实世界问题的能力。这，才是AI Agent开发的真正魅力所在。
觉得有用，别忘了给老金点个赞，关注一下！
[版权声明]
本文由 "技术老金" 原创首发于个人博客及微信公众号『技术老金』，转载请注明出处。
