Multi-Agent 编排实战：LangGraph / AutoGen / CrewAI 三框架对比 + 5 个生产案例
单 Agent 已经搞不定的场景越来越多——故障诊断要 3 个专家、变更审批要 5 步流转、代码评审要 2 个角色——这时候就得用 Multi-Agent 编排。写这篇时我在生产环境里跑过 3 个框架，都踩过超时、成本失控、循环死锁的坑。这篇文章聚焦生产落地，不是"什么是 Agent"科普。
Multi-Agent 的核心是编排（orchestration），也就是怎么让多个 agent 分工协作。目前主流三大框架：LangGraph（状态机，LangChain 生态）、AutoGen（多角色对话，Microsoft 出品）、CrewAI（角色协作，YAML 配置友好）。三家的哲学差异很大，选型错了后面全乱。
1. 三框架核心差异
1.1 LangGraph：状态机编排
核心概念：图 = 节点（Agent/函数）+ 边（转移条件），节点之间传 State。
from langgraph.graph import StateGraph, START, END
from typing import TypedDict
class OpsState(TypedDict):
incident: str
diagnosis: str
plan: str
result: str
needs_human: bool
graph = StateGraph(OpsState)
# 节点
graph.add_node("diagnose", diagnose_agent)
graph.add_node("plan", plan_agent)
graph.add_node("execute", execute_agent)
graph.add_node("human_review", human_review_node)
# 条件边
graph.add_conditional_edges(
"diagnose",
lambda s: "human_review" if s["needs_human"] else "plan",
)
graph.add_edge(START, "diagnose")
graph.add_edge("plan", "execute")
graph.add_edge("human_review", END)
graph.add_edge("execute", END)
app = graph.compile()
result = app.invoke({"incident": "Nginx 502 upstream timeout"})
特点： - ✅ 状态机清晰，每步可预测、可回放 - ✅ 支持 checkpoint，中断后从断点恢复 - ✅ LangSmith 集成好，全链路可观测 - ✅ 支持 human-in-the-loop - ❌ 学习曲线陡，概念多（Node/Edge/State/Reducer） - ❌ 需要显式定义所有状态转移
适合：故障诊断、变更审批、告警路由等有明确状态流转的场景。
1.2 AutoGen：多角色对话
核心概念：多个 AssistantAgent + UserProxyAgent 循环对话，直到终止条件。
from autogen import AssistantAgent, UserProxyAgent
diagnostician = AssistantAgent(
name="diagnostician",
system_message="你是运维诊断专家。收到故障描述后给出可能原因。",
llm_config={"model": "gpt-4o"},
)
remediator = AssistantAgent(
name="remediator",
system_message="你是修复专家。根据诊断给出修复步骤。",
llm_config={"model": "gpt-4o"},
tools=tools, # 可调用工具
)
user_proxy = UserProxyAgent(
name="user_proxy",
human_input_mode="NEVER",
code_execution_config={"work_dir": "workspace"},
)
group = autogen.GroupChat(
participants=[diagnostician, remediator, user_proxy],
speaker_selection_method="round_robin",
message_history_autoset="none",
)
chat = autogen.GroupChatManager(group)
chat.initiate_chat(
user_proxy,
message="Nginx 502 upstream timeout",
max_round=5,
)
特点： - ✅ 上手快，几十行代码就跑通 - ✅ 多角色自然对话，适合开放式任务 - ✅ OpenAI 出品，模型支持最广 - ❌ 状态不明确，难以精确控制流程 - ❌ 循环控制弱，容易陷入死循环（必须 max_round） - ❌ 生产可观测性差
适合：方案评审、代码审查、开放式研究讨论等对话驱动的场景。
1.3 CrewAI：角色协作
核心概念：Crew = 一组 Role，每个 Role 有任务清单，用 YAML 配置。
# crew.yaml
agents:
- role: Incident Researcher
goal: Diagnose the incident and identify root causes
backstory: >
You are a senior SRE with 10 years of experience.
- role: Solution Engineer
goal: Design a fix plan based on diagnosis
backstory: >
You are an expert in system remediation.
- role: Reviewer
goal: Review the fix plan before execution
backstory: >
You are a security-focused reviewer.
tasks:
- description: Analyze the Nginx 502 incident
expected_output: Diagnosis with root cause
agent: Incident Researcher
- description: Design a fix
expected_output: Step-by-step remediation plan
agent: Solution Engineer
- description: Review the fix
expected_output: Approval or rejection with reasons
agent: Reviewer
process: sequential
max_rpm: 30
from crewai import Crew, Agent, Task
diagnostician = Agent(role="Incident Researcher", llm="gpt-4o")
remediator = Agent(role="Solution Engineer", llm="gpt-4o")
reviewer = Agent(role="Reviewer", llm="gpt-4o-mini")
crew = Crew(
agents=[diagnostician, remediator, reviewer],
process=Process.sequential,
verbose=True,
memory=True,
)
crew.kickoff(inputs={"incident": "Nginx 502 upstream timeout"})
特点： - ✅ YAML 配置，非工程师也能定义流程 - ✅ 角色分工明确，任务边界清晰 - ✅ 内置 memory、planning、process - ❌ 灵活性弱，复杂状态机难表达 - ❌ 深度定制受限 - ❌ 与 LangChain 生态整合不如 LangGraph 深
适合：业务型 agent 协作（工单路由、内容生产、数据分析），角色相对固定的场景。
1.4 三框架对比矩阵
| 维度 | LangGraph | AutoGen | CrewAI |
|---|---|---|---|
| 编排模型 | 状态机 + 图 | 多角色对话 | 角色 + 任务 |
| 状态管理 | 显式 State | 隐式消息历史 | Task 输出链 |
| 学习曲线 | 陡 | 平 | 平 |
| 可观测性 | LangSmith 优秀 | 一般 | 一般 |
| Human-in-loop | 内置 | 有限 | 有限 |
| 生产稳定性 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 生态整合 | LangChain 全家桶 | 独立 | 独立 |
| 适合场景 | 故障诊断/审批 | 代码审查/评审 | 内容生产/工单 |
| 上手时间 | 3-5 天 | 半天 | 半天 |
选型铁律： - 有明确状态流转 → LangGraph - 开放式对话协作 → AutoGen - 角色固定业务场景 → CrewAI - 不确定 → LangGraph（最可控）
2. 五个真实生产案例
案例 1：告警诊断 Agent（LangGraph）
场景：Prometheus 报警触发，Agent 自动诊断并给出修复建议。
from langgraph.graph import StateGraph, START, END
from langchain_openai import ChatOpenAI
class DiagnosisState(TypedDict):
alert: dict # Prometheus alert payload
context: dict # 相关上下文（服务、依赖、变更）
diagnosis: str # 诊断结果
action: str # 建议动作
severity: str # P0-P4
needs_human: bool # 是否需要人工介入
llm = ChatOpenAI(model="gpt-4o", temperature=0)
def gather_context(state: DiagnosisState) -> dict:
"""从告警 payload 收集上下文"""
alert = state["alert"]
context = {
"service": alert.get("labels", {}).get("service", ""),
"cluster": alert.get("labels", {}).get("cluster", ""),
"instance": alert.get("labels", {}).get("instance", ""),
"recent_changes": query_recent_changes(alert),
"related_alerts": query_related_alerts(alert),
}
return {"context": context}
def diagnose(state: DiagnosisState) -> dict:
"""LLM 诊断"""
prompt = f"""
根据以下告警和上下文，给出根因分析和修复建议。
告警：{state['alert']}
上下文：{state['context']}
返回 JSON:
{{
"root_cause": "...",
"evidence": ["...", "..."],
"fix_suggestion": "...",
"severity": "P0|P1|P2|P3|P4",
"needs_human": true|false
}}
"""
result = llm.invoke(prompt)
parsed = parse_json(result)
return {
"diagnosis": parsed,
"severity": parsed.get("severity", "P3"),
"needs_human": parsed.get("needs_human", True),
}
def decide_action(state: DiagnosisState) -> str:
"""根据严重度和诊断决定动作"""
if state["severity"] in ("P0", "P1"):
return "human_review"
if state["needs_human"]:
return "human_review"
if "restart" in state["diagnosis"].get("fix_suggestion", ""):
return "human_review" # 高危操作必人工
return "auto_execute"
graph = StateGraph(DiagnosisState)
graph.add_node("gather", gather_context)
graph.add_node("diagnose", diagnose)
graph.add_node("human_review", human_review_node)
graph.add_node("auto_execute", auto_execute_node)
graph.add_edge(START, "gather")
graph.add_edge("gather", "diagnose")
graph.add_conditional_edges(
"diagnose",
decide_action,
{
"human_review": "human_review",
"auto_execute": "auto_execute",
}
)
graph.add_edge("human_review", END)
graph.add_edge("auto_execute", END)
app = graph.compile(checkpointer=MemorySaver())
关键设计： - 上下文收集在诊断之前，避免 LLM 猜 - 高危操作强制人工介入：涉及 restart/redeploy/config_change 必须走 human_review - P0/P1 强制人工：不给 LLM 自作主张的权力
案例 2：变更审批 Agent（LangGraph + 工具）
场景：变更单进入，Agent 自动评估风险、检查依赖、给出审批建议。
class ChangeState(TypedDict):
change_request: dict
risk_score: float
impact_analysis: dict
dependency_check: dict
approval: str # "auto_approve" | "review" | "reject"
tools = [
query_change_history, # 查同类变更历史
check_service_health, # 检查服务健康
check_dependents, # 查下游依赖
check_window, # 检查变更窗口
query_incident_correlation, # 查关联事故
]
def assess_risk(state: ChangeState) -> dict:
"""综合评估风险"""
factors = [
change_size_factor(state["change_request"]),
blast_radius_factor(state["change_request"]),
window_factor(state["change_request"]),
history_factor(state["change_request"]),
]
score = sum(factors) / len(factors)
return {"risk_score": score}
def decide(state: ChangeState) -> str:
if state["risk_score"] < 0.3:
return "auto_approve"
elif state["risk_score"] > 0.7:
return "reject"
else:
return "review"
# 加超时熔断
compiled = graph.compile(
checkpointer=MemorySaver(),
recursion_limit=10, # 防死循环
)
关键设计： - 每一步用工具拿真实数据，不靠 LLM 编 - 风险评分多维度加权 - 三档决策：低分自动通过、高分自动拒绝、中间人工
案例 3：代码审查 Agent（AutoGen）
场景：PR 提交后，多个角色（安全、性能、可读性）并行审查。
security_reviewer = AssistantAgent(
name="security_reviewer",
system_message="你是安全审查专家。关注：SQL 注入、XSS、密钥泄漏、权限问题。",
llm_config={"model": "gpt-4o"},
)
perf_reviewer = AssistantAgent(
name="perf_reviewer",
system_message="你是性能专家。关注：N+1 查询、热点函数、内存泄漏、并发。",
llm_config={"model": "gpt-4o"},
)
readability_reviewer = AssistantAgent(
name="readability_reviewer",
system_message="你是代码质量专家。关注：命名、注释、复杂度、重复。",
llm_config={"model": "gpt-4o-mini"}, # 便宜模型
)
user_proxy = UserProxyAgent(
name="code_owner",
human_input_mode="ALWAYS", # 有人确认
)
# Round-robin 对话，每人审一轮
group = autogen.GroupChat(
participants=[
security_reviewer,
perf_reviewer,
readability_reviewer,
user_proxy,
],
speaker_selection_method="round_robin",
)
chat = autogen.GroupChatManager(group)
chat.initiate_chat(
user_proxy,
message=f"审查这个 PR:\n\n{diff_content}",
max_round=10,
)
关键设计：
- 三个 reviewer 用不同 prompt 和模型（性能/可读性用便宜模型）
- Round-robin 保证每人都有发言
- human_input_mode="ALWAYS" 让 code owner 参与
案例 4：工单路由 Agent（CrewAI）
场景：客户工单进入，Agent 分类、路由、起草回复。
from crewai import Agent, Task, Crew, Process
from crewai_tools import SerperDevTool, GoogleSearch
triage_agent = Agent(
role="工单分类员",
goal="分析工单内容，判断优先级和负责团队",
backstory="10 年一线客服经验，能快速判断工单类型。",
tools=[GoogleSearch],
llm="gpt-4o-mini",
)
writer_agent = Agent(
role="回复撰写员",
goal="根据分类和知识库起草专业回复",
backstory="熟悉公司产品文档，能给出准确的技术解答。",
llm="gpt-4o",
)
reviewer_agent = Agent(
role="回复审核员",
goal="审核回复的专业性和合规性",
backstory="技术专家，熟悉合规红线。",
llm="gpt-4o",
)
triage_task = Task(
description="分析工单内容，给出分类和优先级",
expected_output="JSON: {category, priority, team, summary}",
agent=triage_agent,
)
draft_task = Task(
description="根据分类起草回复",
expected_output="专业的工单回复文本",
agent=writer_agent,
context=[triage_task],
)
review_task = Task(
description="审核回复并给出建议",
expected_output="审核意见：批准/驳回 + 原因",
agent=reviewer_agent,
context=[draft_task],
)
crew = Crew(
agents=[triage_agent, writer_agent, reviewer_agent],
process=Process.sequential,
verbose=True,
memory=True,
)
crew.kickoff(inputs={"ticket": ticket_content})
关键设计：
- 分类用便宜模型（GPT-4o-mini），审核用贵模型
- 三 agent 顺序执行，后一个依赖前一个的输出
- context= 传递上游结果
案例 5：故障诊断多智能体（LangGraph 复杂编排）
场景：生产事故，多 agent 协作诊断，含并行分支和人工介入。
from langgraph.graph import StateGraph, START, END
class IncidentState(TypedDict):
alert: dict
symptoms: dict # 症状清单
root_causes: list # 候选根因
confirmed_root_cause: str
plan: str
executed: bool
needs_human: bool
result: str
# 3 个诊断 agent 并行跑
def parallel_diagnose(state: IncidentState):
"""三个诊断 agent 并行"""
with ThreadPoolExecutor() as pool:
net_result = pool.submit(network_diagnoser, state)
app_result = pool.submit(app_diagnoser, state)
infra_result = pool.submit(infra_diagnoser, state)
return {
"root_causes": [
net_result.result(),
app_result.result(),
infra_result.result(),
]
}
# 汇总 agent
def consolidate(state: IncidentState) -> dict:
"""根据并行结果汇总"""
prompt = f"""
多个诊断 agent 给出了候选根因：
{state['root_causes']}
请判断哪个最可信，给出 confidence 分数。
"""
result = llm.invoke(prompt)
return {
"confirmed_root_cause": result,
"needs_human": result.confidence < 0.7,
}
# 执行 agent（仅低风险动作）
def safe_execute(state: IncidentState) -> dict:
"""低风险动作自动执行，高危拒绝"""
safe_actions = ["restart_pod", "scale_up", "clear_cache"]
if state["plan"] not in safe_actions:
return {"needs_human": True}
return {"executed": True, "result": execute_plan(state["plan"])}
graph = StateGraph(IncidentState)
graph.add_node("gather", gather_symptoms)
graph.add_node("parallel_diagnose", parallel_diagnose)
graph.add_node("consolidate", consolidate)
graph.add_node("plan", plan_agent)
graph.add_node("execute", safe_execute)
graph.add_node("human_review", human_review_node)
graph.add_edge(START, "gather")
graph.add_edge("gather", "parallel_diagnose")
graph.add_edge("parallel_diagnose", "consolidate")
graph.add_conditional_edges(
"consolidate",
lambda s: "human_review" if s["needs_human"] else "plan",
)
graph.add_edge("plan", "execute")
graph.add_conditional_edges(
"execute",
lambda s: "human_review" if s["needs_human"] else END,
)
graph.add_edge("human_review", END)
app = graph.compile(
checkpointer=MemorySaver(),
recursion_limit=15,
)
关键设计：
- 并行诊断：三个领域 agent 同时跑，ThreadPoolExecutor
- 汇总决策：consolidate agent 判断 confidence，低于阈值转人工
- 分级执行：safe_execute 只允许低风险动作，高危自动转人工
3. 生产落地四要点
3.1 超时熔断
每个 agent 设硬超时，避免链路过长：
import asyncio
async def run_agent_with_timeout(agent, state, timeout=30):
try:
return await asyncio.wait_for(agent.invoke(state), timeout=timeout)
except asyncio.TimeoutError:
return {"error": "timeout", "fallback": "human_review"}
# LangGraph 节点里包一层
def diagnose_with_timeout(state: DiagnosisState):
result = run_agent_with_timeout(diagnose_agent, state, timeout=30)
if result.get("error") == "timeout":
return {"needs_human": True, "fallback": "timeout"}
return result
推荐配置： - 单 agent 步长：30 秒 - 整体链路：3-5 分钟 - 超时后走 fallback 路径（通常是人工介入）
3.2 人工介入点
原则：涉及"破坏性操作"必须人工确认，其他可自动化。
必须人工介入的场景： - 重启服务、重启容器、重启节点 - 删除数据、删除资源 - 变更配置、修改数据库 - 涉及支付、涉及用户数据 - P0/P1 级别告警 - 涉及生产环境变更
代码模式：
def decide(state):
risky_ops = ["restart", "delete", "rm", "DROP", "TRUNCATE", "chmod 777"]
if any(op in state["plan"].lower() for op in risky_ops):
return "human_review"
if state["severity"] in ("P0", "P1"):
return "human_review"
return "auto_execute"
3.3 成本控制
三层预算：
# Agent 级预算
class BudgetLLM:
def __init__(self, llm, budget_tokens=5000):
self.llm = llm
self.budget = budget_tokens
self.used = 0
def invoke(self, prompt):
response = self.llm.invoke(prompt)
self.used += response.usage.total_tokens
if self.used > self.budget:
raise BudgetExceededError(f"Exceeded budget {self.budget}")
return response
# 任务级预算
task_budget = 30000
# 模型分级
model_tier = {
"planner": "gpt-4o", # 贵但准
"executor": "gpt-4o-mini", # 便宜够用
"summarizer": "gpt-4o-mini",
"classifier": "gpt-3.5-turbo", # 最便宜
}
成本参考（2026 年 10 月价格）： - GPT-4o：$2.50/M input, $10/M output - GPT-4o-mini：$0.15/M input, $0.60/M output - GPT-3.5-turbo：$0.50/M input, $2.00/M output - Claude 3.5 Sonnet：$3.00/M input, $15/M output - Gemini 1.5 Flash：$0.075/M input, $0.30/M output
经验：一个 Multi-Agent 任务用混合模型，平均成本 $0.05-0.30，比全用 GPT-4o 便宜 5-10 倍。
3.4 可观测性
没有 trace 的 Multi-Agent 就是黑箱：
# 方案 1：LangSmith（LangChain 官方）
import os
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = "ls_xxx"
os.environ["LANGCHAIN_PROJECT"] = "ops-ai-prod"
# 方案 2：Langfuse（开源替代）
os.environ["LANGFUSE_PUBLIC_KEY"] = "pk-xxx"
os.environ["LANGFUSE_SECRET_KEY"] = "sk-xxx"
os.environ["LANGFUSE_HOST"] = "https://langfuse.example.com"
# 方案 3：自建 trace
import structlog
logger = structlog.get_logger()
def traced_node(fn):
async def wrapper(state):
trace_id = state.get("trace_id") or str(uuid4())
node_id = fn.__name__
start = time.time()
try:
result = await fn(state)
logger.info("node_complete",
trace_id=trace_id,
node=node_id,
duration=time.time() - start,
tokens=result.get("usage", {}),
)
return result
except Exception as e:
logger.error("node_failed",
trace_id=trace_id,
node=node_id,
error=str(e),
)
raise
return wrapper
trace 必须包含：
- trace_id：贯穿整条链路
- node_id：当前节点
- step_index：节点内的第几步
- duration_ms：耗时
- tokens_input, tokens_output：token 消耗
- error：错误信息
- state_snapshot：状态快照（可选，敏感数据脱敏）
4. 常见翻车案例
案例 1：死循环
现象：Agent A 让 Agent B 做事，B 又让 A 做，无限循环。
根因：Round-robin 或 handoff 逻辑没终止条件。
修法：
# AutoGen
chat.initiate_chat(user_proxy, message=..., max_round=5)
# LangGraph
compiled = graph.compile(recursion_limit=10)
# 状态里加计数器
class State(TypedDict):
round: int
def agent_a(state):
if state["round"] > 5:
return {"stop": True}
return {"round": state["round"] + 1, ...}
案例 2：token 爆炸
现象：单个任务烧了 $50+，因为 agent 之间消息不断累积。
修法：
# 消息压缩
def compress_history(messages, max_tokens=2000):
if count_tokens(messages) > max_tokens:
summary = llm.invoke(f"总结以下对话要点:\n{messages}")
return [SystemMessage(summary)] + messages[-2:]
return messages
# Agent 之间传摘要不传全量
agent_b_input = compress_history(agent_a_output, max_tokens=2000)
案例 3：状态不一致
现象：Agent A 修改了 state，Agent B 又改回去了，最后状态混乱。
修法：
# LangGraph 用 reducer
class State(TypedDict):
root_causes: Annotated[list, operator.add] # 追加而不是覆盖
decisions: Annotated[list, operator.add]
# 或者用 checkpoint
compiled = graph.compile(checkpointer=MemorySaver())
config = {"configurable": {"thread_id": "incident-123"}}
result = compiled.invoke(state, config) # 状态保存
案例 4：模型幻觉
现象：Agent 编造了不存在的 API 调用，执行失败。
修法：
# 工具白名单
allowed_tools = [
"kubectl_get_pods",
"kubectl_describe_pod",
"curl_http", # 只允许 GET
]
agent = Agent(
tools=allowed_tools,
# 其他工具一律禁止
)
# 结果验证
def verify_action(action: dict) -> bool:
if action["command"].startswith("kubectl delete"):
return False # 高危
if action["command"].startswith("rm "):
return False
return True
案例 5：LLM 不遵循 JSON 格式
现象：Agent 输出应该返回 JSON 但经常漏字段或加解释。
修法：
# 结构化输出（LangChain）
from pydantic import BaseModel
class Diagnosis(BaseModel):
root_cause: str
evidence: list[str]
fix: str
severity: Literal["P0", "P1", "P2", "P3", "P4"]
result = llm.with_structured_output(Diagnosis).invoke(prompt)
# result 类型保证是 Diagnosis
# 或者提示词强化
prompt = """
返回严格的 JSON，不要任何其他内容：
{
"root_cause": "...",
"evidence": ["...", "..."],
"fix": "...",
"severity": "P0|P1|P2|P3|P4"
}
"""
5. FAQ
Q1: Multi-Agent 一定比单 Agent 好吗？
A: 不一定。单 Agent 加工具集能解决 80% 的问题，成本还低。Multi-Agent 只在这些场景值得用：① 任务复杂到单 agent prompt 塞不下 ② 需要不同角色（安全 vs 性能）分工 ③ 需要明确的状态流转（审批链）④ 需要 human-in-the-loop。能用单 Agent 就用单 Agent，Multi-Agent 是最后手段。
Q2: Multi-Agent 是不是需要更强的模型？
A: 相反。每个 Agent 可以做更窄的任务，反而可以用便宜模型。编排的价值在于"分而治之"：复杂任务拆给多个便宜模型，比一个贵模型搞复杂任务更省钱更稳。
Q3: Agent 之间的通信怎么设计？
A: 三种模式：① 消息传递（AutoGen）：agent 之间对话，消息累积 ② 状态共享（LangGraph）：agent 读写同一 state，通过 reducer 合并 ③ 消息队列（自定义）：agent 通过 Kafka/Redis 异步通信。生产环境推荐 LangGraph 状态机模式，最可控。
Q4: 怎么处理 Agent 出错重试？
A: 三层策略：① 节点级重试：LangGraph 节点可配置 retry 3 次指数退避 ② 任务级 fallback：某节点连续失败 3 次走 fallback 路径 ③ 链路级人工介入：整条链路超时或多次失败转人工。
from langgraph.types import RetryPolicy
node = graph.add_node(
"diagnose",
diagnose_agent,
retry=RetryPolicy(max_attempts=3, backoff_factor=2),
)
6. 常见误区
| 误区 | 真相 |
|---|---|
| "Multi-Agent 是趋势，越复杂越好" | 单 Agent 加工具集能解决 80% 问题，别过度设计 |
| "LangGraph 复杂，AutoGen 简单" | 复杂性来自任务本身，选错框架再简单也解决不了 |
| "Agent 越多越聪明" | 每个 agent 都增加成本和延迟，5+ agent 就该评估是否拆分任务 |
| "LLM 是决策大脑，agent 只是执行" | 现代 agent 强调工具使用，LLM 只是 planner，tool 才是手脚 |
| "Multi-Agent 可以完全自动化" | 涉及生产变更必须 human-in-the-loop，这是底线不是可选项 |
7. 关联阅读
- AI Agent 架构设计 — ReAct/Plan-and-Execute 三大模式原理
- LangChain 应用开发 — Chain/Memory/Agent 实战
- AI 运维自动化 — Agent 编排 + 告警处理
- MCP 协议 — 工具调用标准