企业官网建设流程全解析

1. 这不是选“最好”的框架，而是选“最不拖后腿”的那个

你打开 GitHub，搜 multi-agent framework，页面刷出二十多个星标过千的项目；点进文档，每家都在说“我们支持复杂工作流”“天然适配 LLM 编排”“开箱即用的 Agent 协作机制”。但真正把 CrewAI、LangGraph、AutoGen 三个主流框架拉到同一张表里跑完一个真实任务——比如让 AI 团队自动完成“竞品周报生成：爬取官网更新 → 提取功能变更 → 对比我方版本 → 输出带图表的 PPT 备注稿”——你会发现：不是谁功能多，而是谁在关键节点上不掉链子。

我过去两年带过 7 个跨团队 AI 工程落地项目，其中 4 个中途重构了 Agent 架构。踩坑最多的一次，是用 AutoGen 的 GroupChatManager 跑金融研报生成，结果在“分析师角色反复质疑数据源可信度”这个环节卡死 36 小时——不是模型不行，是框架没提供可中断的 human-in-the-loop 介入点，也没法把质疑逻辑单独抽出来做单元测试。后来换成 LangGraph 的 StateGraph + Conditional Edge，把“数据可信度校验失败”定义为一个显式状态分支，整个流程立刻变得可调试、可监控、可灰度。

CrewAI、LangGraph、AutoGen 的核心差异，根本不在 API 写得漂不漂亮，而在于它们对“协作失控”这件事的预设态度：CrewAI 默认信任角色分工，把异常当作边缘情况；LangGraph 把协作本身建模为状态机，所有分支都必须显式声明；AutoGen 则试图用对话历史回溯来模拟人类协商，但一旦协商路径变长，就容易陷入语义漂移。这直接决定了你在第 3 天调试时是花 20 分钟改个 condition 函数，还是花 3 小时翻 chat history 找哪句话触发了错误路由。

这篇文章不给你列“功能对比表”，因为那玩意儿在真实项目里毫无意义。我会带你用同一个业务场景（电商大促前的库存-营销联动分析），完整走一遍三个框架的实现逻辑，告诉你每个关键决策点背后的真实代价：比如 CrewAI 的 Task 依赖链看着清爽，但当你需要让“库存预警 Agent”在发现缺货时，跳过常规审批流直连“营销补偿 Agent”时，它的硬编码依赖会逼你重写整个 Crew 初始化逻辑；而 LangGraph 的 state schema 强制你提前定义所有可能字段，看似啰嗦，却让你在第 5 次迭代时，能直接复用 80% 的状态转换代码。

适合谁读？如果你正在技术选型会上被老板问“哪个框架下周就能跑通 MVP”，或者已经写了三天 Agent 却卡在“为什么这个角色就是不按指令执行”，又或者正被 QA 质疑“你们怎么保证 Agent 输出的促销文案不违反广告法”，那你需要的不是概念科普，而是知道在哪个环节该咬牙加一行 config，哪个地方必须推倒重来。接下来的内容，全部来自我们团队在 3 个真实交付项目中留下的 debug 日志、架构评审记录和凌晨三点的 Slack 截图。

2. 框架设计哲学拆解：从“怎么写代码”到“怎么防崩溃”

2.1 CrewAI：面向角色的工程化封装，强约定弱控制

CrewAI 的设计原点很务实：让非算法背景的产品经理也能描述清楚“谁该干什么”。它把 Agent、Task、Process 三层抽象成类，用 Pythonic 的链式调用组织流程。比如一个基础的“内容审核流水线”，代码可能长这样：

researcher = Agent( role="Market Researcher", goal="Find latest pricing trends for smartwatches", backstory="5 years in consumer electronics analysis" ) writer = Agent( role="Content Writer", goal="Draft engaging product comparison blog post", backstory="Ex-marketing copywriter at TechCrunch" ) task_research = Task( description="Search for Q2 2024 smartwatch pricing data from Apple, Samsung, Huawei", agent=researcher ) task_write = Task( description="Write a 800-word comparison blog post using the research data", agent=writer, context=[task_research] # 显式声明依赖 ) crew = Crew( agents=[researcher, writer], tasks=[task_research, task_write], process=Process.sequential # 或 hierarchical )

这段代码的“爽点”在于：角色定义贴近业务语言，任务依赖一目了然，process 参数直接对应管理学概念。但它的底层约束藏在细节里：context=[task_research]这行代码，实际触发的是 CrewAI 内部的task_output_to_string()方法，它会把 researcher 的输出强制转成字符串塞进 writer 的 prompt。这意味着——如果你的研究员 Agent 返回的是结构化 JSON（比如{ "price_changes": [{"brand": "Apple", "change_pct": -3.2}] }），Writer 的 prompt 里看到的只是一段带换行符的文本，而不是可解析的对象。我们曾因此在“生成价格对比表格”环节失败：Writer 总是把 JSON 当普通文字渲染，生成的 Markdown 表格列全乱了。

更关键的是 Process 模式。Process.sequential看似简单，但它隐含一个强假设：前序 Task 的输出，100% 符合后序 Task 的输入预期。当 researcher 因网络超时返回空字符串，writer 不会报错，而是拿着空上下文继续生成——结果是一篇通篇用“根据数据显示…”开头的玄学文章。CrewAI 没有内置的 output validation hook，你要么在每个 Task 的output_pydantic里写校验逻辑（增加心智负担），要么在 Crew 执行后手动检查crew.usage_metrics（但此时错误已发生）。

提示：CrewAI 真正的适用边界，是那些“角色职责清晰、任务输出格式稳定、失败容忍度高”的场景。比如内部知识库问答（查不到就返回“未找到”）、标准化报告生成（模板固定，字段缺失可默认填充）。一旦涉及多轮动态协商或强数据契约，它的封装反而会成为调试障碍。

2.2 LangGraph：状态驱动的确定性编排，用图灵机思维写 AI 流程

LangGraph 的设计哲学截然不同。它不预设“角色”，而是把整个协作过程看作一个状态机。每个节点（Node）是一个纯函数，接收当前状态（State），返回新状态；每条边（Edge）是一个条件函数，决定下一步走向哪里。这种设计牺牲了初期上手速度，却换来极强的可观测性和可控性。

还是上面的电商分析场景，LangGraph 的实现核心是定义 State 和 Nodes：

from typing import TypedDict, Annotated, List from langgraph.graph import StateGraph, END from langgraph.checkpoint.memory import MemorySaver class AnalysisState(TypedDict): # 必须显式声明所有可能用到的字段 raw_data: str inventory_status: dict marketing_suggestions: List[str] needs_human_review: bool error_message: str def fetch_inventory_node(state: AnalysisState) -> AnalysisState: try: # 实际调用库存API status = call_inventory_api() return {"inventory_status": status, "error_message": ""} except Exception as e: return {"error_message": f"Inventory fetch failed: {str(e)}"} def generate_suggestions_node(state: AnalysisState) -> AnalysisState: if state["error_message"]: return {"needs_human_review": True} # 基于 inventory_status 生成建议 suggestions = llm_generate_suggestions(state["inventory_status"]) return {"marketing_suggestions": suggestions} # 定义条件边：决定是否需要人工审核 def should_review(state: AnalysisState) -> str: return "human_review" if state["needs_human_review"] else "end" # 构建图 workflow = StateGraph(AnalysisState) workflow.add_node("fetch_inventory", fetch_inventory_node) workflow.add_node("generate_suggestions", generate_suggestions_node) workflow.add_node("human_review", lambda s: s) # 占位，实际接人工接口 workflow.set_entry_point("fetch_inventory") workflow.add_edge("fetch_inventory", "generate_suggestions") workflow.add_conditional_edges( "generate_suggestions", should_review, { "human_review": "human_review", "end": END } )

这段代码的“笨重感”恰恰是它的优势。AnalysisState强制你提前思考所有可能的状态字段，should_review函数把业务规则（什么情况下需人工）从 LLM 逻辑里剥离出来。当 inventory API 返回异常时，fetch_inventory_node直接在error_message字段写入错误，generate_suggestions_node看到非空error_message就跳过生成逻辑，should_review函数自然导向human_review分支——整个流程没有魔法，每一步的输入输出都可打印、可断点、可单元测试。

LangGraph 的 checkpoint 机制更是杀手锏。我们在线上环境配置MemorySaver()，每次流程中断（比如人工审核中），系统自动保存当前 State 到内存。运营人员在后台点击“通过审核”后，流程从断点处恢复，generate_suggestions_node重新执行，但这次state["error_message"]是空的，于是正常生成建议。这种能力在 CrewAI 里需要自己实现 Redis 存储 + 自定义回调，而在 LangGraph 里，一行checkpointer=MemorySaver()就搞定。

注意：LangGraph 的学习曲线陡峭，尤其对习惯“面向对象”思维的工程师。但它的回报是：当你的流程从 3 步扩展到 12 步，涉及 5 个外部系统调用和 3 类人工审核节点时，你依然能用graph.get_graph().draw_mermaid_png()（注：此处 mermaid 仅用于本地调试生成流程图，生产环境不依赖）一眼看清数据流向，而不是在 200 行 Crew 初始化代码里找哪个 Task 的 context 没传对。

2.3 AutoGen：对话历史驱动的协商模拟，把 LLM 当人用

AutoGen 的设计最激进：它不抽象“任务”或“状态”，而是把整个协作建模为多角色对话。Agent 是对话参与者，GroupChat 是聊天室，GroupChatManager 是群聊管理员。它的核心假设是：人类专家协作的本质就是对话，所以让 LLM 模拟对话，就能复现协作智能。

继续电商场景，AutoGen 的典型写法：

from autogen import AssistantAgent, UserProxyAgent, GroupChat, GroupChatManager inventory_agent = AssistantAgent( name="Inventory_Analyst", system_message="You are an expert in supply chain analytics. Analyze inventory levels and flag risks.", llm_config={"config_list": config_list} ) marketing_agent = AssistantAgent( name="Marketing_Strategist", system_message="You design promotional campaigns. Suggest compensations for inventory shortages.", llm_config={"config_list": config_list} ) user_proxy = UserProxyAgent( name="Admin", code_execution_config={"use_docker": False}, human_input_mode="ALWAYS" # 关键！人工可随时介入 ) groupchat = GroupChat( agents=[inventory_agent, marketing_agent, user_proxy], messages=[], max_round=12, speaker_selection_method="round_robin" # 或 auto（让LLM选下一个说话人） ) manager = GroupChatManager( groupchat=groupchat, llm_config={"config_list": config_list} ) # 启动对话 user_proxy.initiate_chat( manager, message="Analyze current inventory for SKU 'WATCH-X2024' and suggest marketing actions if shortage detected." )

这段代码的魔力在于speaker_selection_method="auto"。AutoGen 会让 LLM 阅读整个对话历史，然后决定“现在该谁发言”。比如 inventory_agent 发现缺货后，它可能在下一条消息里写：“@Marketing_Strategist，我检测到 WATCH-X2024 库存低于安全阈值，请基于此设计紧急促销方案。”——这个 @ 提及动作，就是 AutoGen 的路由机制。

但问题也源于此。当对话轮次超过 8 轮，history token 快爆满时，LLM 可能因上下文压缩丢失关键信息。我们曾遇到：inventory_agent 在第 3 轮说“缺货 200 台”，到第 9 轮 marketing_agent 提议“发放 200 张 5 折券”，结果 LLM 把“200 台”记成了“200 张”，导致补偿力度错配。AutoGen 没有强制的结构化数据传递，一切依赖 LLM 对文本的理解稳定性。

更隐蔽的陷阱是human_input_mode。设为"ALWAYS"确保人工可控，但每次人工输入都算一轮对话，会快速耗尽max_round。设为"NEVER"则完全失去干预能力。我们最终采用折中方案：human_input_mode="TERMINATE"，即只在特定关键词（如 “HUMAN REVIEW REQUIRED”）出现时暂停，并用正则匹配自动提取关键词——这需要你深入理解 AutoGen 的_process_received_message源码，自己 patch 一个中间件。

实操心得：AutoGen 最适合“探索性强、规则模糊、需要人类实时引导”的场景。比如新产品上市策略脑暴（没有标准答案，靠多角度碰撞）、客户投诉深度分析（需结合情绪、事实、政策多维度解读）。但凡存在明确的数据契约（如“库存数据必须包含 sku_id, qty, last_update”）或强 SLA（如“从触发到生成建议必须 < 90 秒”），AutoGen 的对话黑箱就会成为性能和质量瓶颈。

3. 实操对比：同一个电商分析需求，在三个框架中的落地细节

3.1 需求再确认：不是“做个 Demo”，而是“上线跑一周”

我们选定的验证需求是：大促前 72 小时，自动分析 TOP10 SKU 的库存健康度，并生成对应的营销补偿建议，全程无人值守，SLA ≤ 120 秒/次，错误率 < 0.5%。

这个需求的关键约束：

• 数据契约刚性：库存 API 返回 JSON 必须含sku_id,current_qty,safety_stock,last_updated字段；
• 决策逻辑分层：先判断是否缺货（current_qty < safety_stock），再判断缺货严重程度（shortage_ratio = (safety_stock - current_qty) / safety_stock），最后按 severity 分级给建议；
• 人工兜底通道：当shortage_ratio > 0.8（即缺货超 80% 安全库存）时，必须暂停并通知运营人员确认；
• 审计要求：每次执行必须记录原始库存数据、计算过程、最终建议、执行时间戳。

这三个约束，像三把尺子，精准丈量每个框架的工程成熟度。

3.2 CrewAI 实现：优雅的表象与脆弱的内核

在 CrewAI 中，我们构建了 3 个 Agent：InventoryFetcher、RiskAnalyzer、CompensationPlanner，以及 2 个 Task：fetch_inventory和analyze_and_plan。

# 关键难点：如何让 RiskAnalyzer 知道何时该触发人工审核？ # CrewAI 没有内置的“条件分支”概念，我们被迫在 Task 内部做 hack class RiskAnalyzer(Agent): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.human_review_threshold = 0.8 # 硬编码，不灵活 # 在 analyze_and_plan Task 的 execute 方法里 def _execute(self, inputs): raw_data = inputs["raw_data"] # 来自 fetch_inventory 的输出 try: data = json.loads(raw_data) # 假设 fetcher 返回 JSON 字符串 shortage_ratio = (data["safety_stock"] - data["current_qty"]) / data["safety_stock"] if shortage_ratio > self.human_review_threshold: # 这里不能直接 halt，只能返回特殊字符串 return "HUMAN_REVIEW_REQUIRED:" + json.dumps(data) else: return generate_compensation(data) except Exception as e: return f"ERROR:{str(e)}"

这个 hack 带来两个严重问题：

1. 输出污染：CompensationPlanner的 prompt 里必须写明“如果看到 HUMAN_REVIEW_REQUIRED，不要生成任何建议，只需提取 JSON 并发送给运营系统”，这增加了 LLM 的理解负担，错误率上升；
2. 审计断裂：CrewAI 的crew.kickoff()返回的是最终输出字符串，要拿到中间的raw_data和shortage_ratio，必须重写Crew类的_log方法，侵入框架源码。

我们实测了 100 次运行：平均耗时 98 秒，但错误率高达 3.2%（主要因 JSON 解析失败和 LLM 忽略 HUMAN_REVIEW_REQUIRED 指令）。当把human_review_threshold从 0.8 改为 0.75 时，需要修改 3 个地方（Agent 初始化、Task execute、Prompt 指令），且无法做 A/B 测试。

经验教训：CrewAI 的“低代码”本质是“低调试代码”。它把复杂性从实现层转移到了 prompt 工程和异常处理层。如果你的团队没有专职的 Prompt 工程师，或者 QA 无法用自动化脚本验证每个 Task 的输出格式，CrewAI 会迅速变成运维噩梦。

3.3 LangGraph 实现：冗长但可靠的确定性

LangGraph 的实现严格遵循需求约束，State 定义直接映射业务字段：

class EcommerceState(TypedDict): sku_id: str raw_inventory_json: str # 原始API响应，保留原始数据供审计 current_qty: int safety_stock: int shortage_ratio: float compensation_suggestion: str needs_human_review: bool audit_log: List[dict] # 记录每步操作 # Node 1: 解析库存API响应 def parse_inventory_node(state: EcommerceState) -> EcommerceState: try: data = json.loads(state["raw_inventory_json"]) # 强制校验字段 assert "sku_id" in data and "current_qty" in data and "safety_stock" in data ratio = (data["safety_stock"] - data["current_qty"]) / data["safety_stock"] audit_entry = { "step": "parse_inventory", "timestamp": time.time(), "input": state["raw_inventory_json"], "output": {"current_qty": data["current_qty"], "safety_stock": data["safety_stock"], "ratio": ratio} } return { "current_qty": data["current_qty"], "safety_stock": data["safety_stock"], "shortage_ratio": ratio, "audit_log": state.get("audit_log", []) + [audit_entry] } except Exception as e: return {"error_message": f"Parse failed: {e}"} # Node 2: 决策节点，纯业务逻辑 def decision_node(state: EcommerceState) -> EcommerceState: if state.get("error_message"): return {"needs_human_review": True} if state["shortage_ratio"] > 0.8: return {"needs_human_review": True} else: suggestion = generate_suggestion(state["shortage_ratio"]) return {"compensation_suggestion": suggestion} # 条件边：清晰分离关注点 def route_to_human_or_end(state: EcommerceState) -> str: return "human_review" if state["needs_human_review"] else "end"

整个流程的可靠性来自三点：

• Schema 强校验：parse_inventory_node里的assert在第一环节就拦截非法数据，错误直接进入error_message字段；
• 审计内建：audit_log是 State 的一部分，每次return都自动追加，无需额外日志组件；
• 决策外置：shortage_ratio > 0.8这个业务规则写在decision_node里，而不是藏在某个 Agent 的 system_message 中，方便单元测试和参数化。

我们用 pytest 写了 12 个测试用例（覆盖正常、缺字段、负库存、ratio=0.81 等边界），全部通过。100 次压测平均耗时 105 秒，错误率 0.3%，全部是库存 API 超时导致，与框架无关。当需要将阈值从 0.8 改为 0.75 时，只改decision_node里一行代码，5 秒完成。

实操技巧：LangGraph 的StateGraph允许你用add_edge("node_a", "node_b")创建无条件边，用add_conditional_edges("node_a", condition_func)创建条件边。但要注意，condition_func 必须返回字符串，且该字符串必须是图中已存在的节点名（或END）。我们曾因返回"human_review_node"（多写了_node）导致流程静默失败，调试时用print(graph.nodes)查看有效节点名才定位到问题。

3.4 AutoGen 实现：灵活的表象与不可控的内核

AutoGen 的实现最“自然”，但最不可控。我们创建了InventoryBot、RiskBot、CompensationBot三个 AssistantAgent，并设置speaker_selection_method="auto"。

# 关键：用 system_message 注入决策逻辑 risk_bot = AssistantAgent( name="RiskBot", system_message=""" You are a risk analyst. Your job is to calculate shortage_ratio from inventory data. If shortage_ratio > 0.8, you MUST output exactly: 'HUMAN REVIEW REQUIRED: [JSON with sku_id, current_qty, safety_stock]' Do NOT generate any other text. Do NOT explain. Just output that string. """, llm_config=llm_config )

这个设计的问题在于：system_message的指令效力完全依赖 LLM 的遵循度。GPT-4 通常能遵守，但当我们切换到成本更低的 Claude Haiku 时，它开始在HUMAN REVIEW REQUIRED后面加解释性文字，导致下游CompensationBot误解析。

更麻烦的是审计。AutoGen 的groupchat.messages是一个列表，记录所有对话，但格式是：

[ {"role": "user", "content": "Analyze SKU..."}, {"role": "assistant", "content": "I'll fetch inventory...", "name": "InventoryBot"}, {"role": "assistant", "content": "HUMAN REVIEW REQUIRED: {...}", "name": "RiskBot"} ]

要提取shortage_ratio，你得：

1. 找到RiskBot的消息；
2. 用正则r'HUMAN REVIEW REQUIRED: ({.*})'提取 JSON；
3. 解析 JSON 得到current_qty和safety_stock；
4. 自己计算shortage_ratio。

这违背了“审计要求”中“记录计算过程”的条款——AutoGen 只记录了结果（HUMAN REVIEW REQUIRED），没记录计算过程。

我们尝试用register_function注册一个计算函数，但 AutoGen 的 function calling 机制在 GroupChat 中不稳定，经常被 LLM 忽略。最终方案是：在RiskBot的generate_reply方法里硬编码计算逻辑，并用self._send_message()主动推送结构化结果到groupchat.messages——这相当于给 AutoGen 打了一个补丁，但补丁代码长达 80 行，且每次 AutoGen 升级都可能失效。

100 次测试中，错误率 2.1%，耗时波动极大（72~145 秒），峰值出现在第 9 轮对话时——因为max_round=12，LLM 在后期更倾向于生成简短回复，导致HUMAN REVIEW REQUIRED字符串被截断。

独家避坑：AutoGen 的GroupChatManager有一个隐藏参数allow_repeat_speaker=False（默认 True）。设为 False 可防止同一个 Agent 连续发言，避免对话陷入死循环。但我们发现，当speaker_selection_method="auto"且allow_repeat_speaker=False时，LLM 有时会因找不到“合适”的下一个发言人而返回空消息，导致流程卡死。解决方案是：永远设置allow_repeat_speaker=True，并在每个 Agent 的generate_reply里加超时保护。

4. 关键决策点对照表与实战排查指南

4.1 框架选型决策树：5 个问题决定你的选择

我们把选型过程浓缩为一张决策树，每个问题都来自真实项目踩坑：

这张表不是理论推导，而是我们 7 个项目复盘的结果。例如，一个保险理赔项目，最初选 CrewAI 因为“产品经理能看懂”，但上线两周后，监管要求新增“拒赔理由必须引用具体条款编号”，这需要修改 5 个 Task 的 prompt 并重新测试，耗时 3 天。后来切到 LangGraph，只改了decision_node里一行if clause_ref not in policy_db: raise ValidationError，10 分钟上线。

4.2 常见故障速查表：从报错日志反推根因

当你的 Agent 流程失败时，别急着重跑，先看日志类型：

这张表里的每个条目，都对应我们团队 Slack 里一个带时间戳的故障复盘。比如“AutoGen 空回复”问题，发生在一次深夜发布后，原因是新接入的 Claude 模型对system_message中的“MUST”指令过于敏感，遇到不确定时直接返回空——这个细节，官方文档从未提及。

4.3 性能与成本实测数据：别信宣传页的 Benchmark

我们在 AWS c5.2xlarge（8vCPU/16GB）机器上，用相同 LLM（gpt-4-turbo）和相同库存数据集（10 个 SKU 的 JSON），实测三个框架的资源消耗：

数据说明：

• LangGraph 内存最低：因为它不缓存整个对话历史，只存当前 State；
• AutoGen CPU 最高：speaker_selection_method="auto"需要 LLM 阅读全部 history 做推理，history 越长，CPU 越高；
• CrewAI token 消耗居中：它的context传递会把前序 Task 输出拼进 prompt，但不会像 AutoGen 那样累积全部轮次；
• 错误重试次数：AutoGen 最高，因为它的“协商”本质意味着更多不确定性，一次失败往往需要重跑整段对话。

成本上，LangGraph 最省：1.8M tokens × $0.01/1K tokens = $18；AutoGen 最贵：$27。但这只是 LLM 成本，若算上运维成本（AutoGen 故障率高，需更多人力盯盘），实际差距更大。

实测心得：我们曾为降本把 CrewAI 切到 claude-3-haiku，结果错误率从 3.2% 暴涨到 12.7%。不是模型不行，而是 CrewAI 的Task.context机制让 haiku 在长上下文里更容易忽略关键指令。最终方案是：对关键 Task（如风险判断）坚持用 gpt-4-turbo，非关键 Task（如文案润色）用 haiku——这需要框架支持混合模型，而 LangGraph 的Node设计天然支持，CrewAI 需要 hackllm_config，AutoGen 则必须为每个 Agent 单独配置，管理成本飙升。

5. 我的个人经验：什么时候该放弃“选框架”，直接手写

干这行十年，我见过太多团队在“选框架”上纠结三个月，最后发现——真正的瓶颈从来不在框架，而在数据管道和领域知识注入。

去年我们帮一家连锁药店做“慢病用药提醒”Agent，需求是：当用户处方药库存 < 7 天用量时，自动发短信提醒续方。听起来简单，但落地时发现：

• 药店 ERP 系统返回的“库存”字段，实际是“在库数量”，不包含“在途采购”和“门店间调拨”；
• “7 天用量”需要根据患者历史购药频次动态计算，而历史数据分散在 3 个数据库；
• 短信模板要符合《药品广告管理办法》，不能出现“治愈”“根治”等词。

我们试了 CrewAI：用PrescriptionAgent+InventoryAgent+ComplianceChecker，但InventoryAgent总拿不到准确的“可用库存”，因为 ERP API 文档写的是“库存”，实际含义是“在库”。团队花了 11 天写各种 workaround，最后发现，与其让 CrewAI 去猜 ERP 的潜规则，不如写一个 200 行的 Python 脚本，专门对接 ERP，把“可用库存”算准，再喂给 CrewAI。

LangGraph 也一样。