Agent 为什么 Demo 很炫、上线很难？自己想、自己干、自己复盘才是关键

上周有个同学问我： "我这个客服机器人已经能查订单、查物流、改地址了，算不算 Agent？"

我反问了三个问题：

它查不到订单时，会不会自己判断是参数缺失、接口失败，还是用户问题问错了？ 它调用改地址接口前，会不会先确认权限、地址格式、订单状态？ 它改完以后，会不会检查结果，并在失败时换一种路径继续处理？

如果答案都是不会，那它更像一个"会调用工具的聊天机器人"。

真正的 Agent，不只是会聊天，也不只是会调 API。能自己想、自己干、自己复盘，才算进入 Agent 的门。

Agent 到底是什么

一句话讲：

★Agent 是一个围绕目标运行的智能执行循环。

它不是一次问答，而是一段过程。

普通 LLM 应用通常是这样：

用户问题 -> 模型回答 -> 结束

工具调用应用通常是这样：

用户问题 -> 模型选择工具 -> 调用工具 -> 模型总结 -> 结束

Agent 更像这样：

目标 -> 规划 -> 执行工具 -> 观察结果 -> 调整计划 -> 继续执行 -> 复盘 -> 结束

核心差异在这里：

所以，Agent 不是一个新组件，而是一种系统形态。

好 Agent 的三个标准

我更喜欢用三个词判断 Agent：想、干、复盘。

自己想：不是瞎想，而是可控规划

Agent 的"想"，不是让模型自由发挥。

线上系统最怕一句话：

你是一个聪明的助手，请自主完成用户任务。

听起来很强，对吧？ 但这句话放到生产环境里，基本等于把方向盘交给一个没有刹车记录的人。

一个可控的规划至少要包含：

目标：用户要完成什么
约束：哪些事情不能做
工具：可以使用哪些能力
状态：目前已经知道什么
停止条件：什么时候算完成
失败策略：失败以后怎么办

比如订单客服 Agent，不应该只写：

帮用户处理订单问题

而应该写成：

目标：解决用户订单查询、物流查询、地址修改问题
约束：不能修改已发货订单地址；不能暴露其他用户订单
工具：get_order、get_shipping、update_address
停止条件：用户确认问题解决，或明确转人工
失败策略：接口失败重试一次，权限不满足时解释原因并转人工

这才是工程里的"自己想"。

自己干：不是能调工具，而是会安全地调工具

很多 Agent demo 看起来很炫，是因为它会连续调用工具。

但上线以后，最容易出事的也是工具调用。

比如模型生成了这样的调用：

{
  "tool": "update_address",
  "arguments": {
    "orderId": "123",
    "address": "用户刚才提到的地址"
  }
}

问题来了：

这个订单是不是当前用户的？ 订单状态是否允许修改？ 地址有没有结构化校验？ 这个工具是否需要二次确认？

所以工具层一定要做硬校验：

def update_address(user_id: str, order_id: str, address: dict):
    order = order_service.get_order(order_id)

    if order.user_id != user_id:
        raise PermissionError("order does not belong to current user")

    if order.status not in ["CREATED", "PAID"]:
        raise ValueError("order address can no longer be changed")

    if not address_validator.is_valid(address):
        raise ValueError("invalid address")

    return order_service.update_address(order_id, address)

重点不是代码多复杂，而是边界要清楚：

模型负责判断意图，系统负责守住权限、状态和数据一致性。

不要让 LLM 的一句话绕过业务规则。

自己复盘：没有观察和评估，就只是自动脚本

Agent 最容易被忽略的能力是复盘。

工具调用结束以后，Agent 必须看结果。

调用 get_order 成功了吗？
返回值是否为空？
返回值是否和用户问题相关？
下一步是否还需要调用别的工具？
最终答案有没有解决用户目标？

工程上，这对应三类东西：

OpenAI Agents SDK 把 tracing、handoff、guardrails 放成一等能力；LangGraph 强调状态图和可控流程；Microsoft Agent Framework 也把 workflows、memory、persistence、hosting 放进文档主线。这些设计背后的共同点是：Agent 不是一次生成，而是一条可观察的执行链路。

一个最小 Agent 长什么样

最小 Agent 可以先不要框架，先理解循环：

while not done:
    plan = llm.decide(
        goal=goal,
        state=state,
        tools=available_tools
    )

    if plan.type == "tool_call":
        result = call_tool(plan.tool, plan.arguments)
        state.add_observation(result)

    elif plan.type == "final_answer":
        done = True
        answer = plan.content

    else:
        state.add_error("unknown action")

这段代码很粗糙，但它讲清楚了 Agent 的本质：

模型不是直接给最终答案，而是在一个循环里不断做决策。 每一步执行后，结果会回到状态里，影响下一步选择。

生产环境会在这个循环上继续加东西：

权限校验
参数校验
工具超时
重试策略
人工接管
成本控制
Trace 记录
上下文压缩
评估样本
灰度开关

所以别一上来就迷信多 Agent。 很多业务场景，一个单 Agent 加清晰工具边界，比五个角色互相聊天更稳定。

主流 Agent 框架怎么选

截至 2026-05-28，主流 Agent 框架大致可以分成几类。

LangChain / LangGraph：适合复杂流程，但要管住复杂度

LangChain 的优势是生态大，工具集成多。官方文档里的 Agent 已经围绕 create_agent、tools、middleware 等能力组织。

但如果你要做的是长流程、可恢复、可观察的 Agent，重点通常会落到 LangGraph：状态、节点、边、检查点、条件跳转。

适合场景：

审批流 Agent
代码分析 Agent
多步骤数据处理
需要中断恢复的长任务

风险也很明显：抽象层多以后，问题不一定出在模型，可能出在状态传递、工具包装、版本兼容和回调链路。

LlamaIndex：知识库 Agent 首选之一

如果你的核心问题是"Agent 怎么理解企业内部数据"，LlamaIndex 很合适。

它的强项不是让多个 Agent 开会，而是把文档、索引、检索、查询引擎和工具组织起来，让 Agent 能围绕数据工作。

适合场景：

企业知识库
合同问答
研报分析
客服知识检索
文档工作流

但要注意，RAG Agent 的难点不在"能不能查"，而在"查得准不准、引用对不对、上下文有没有污染"。

CrewAI：适合角色分工明确的协作任务

CrewAI 的表达方式很直观： 一个 crew 里有多个 agent，每个 agent 有 role、goal、backstory，再配 task。

这对内容生产、调研、报告生成这类任务很友好。

比如：

研究员 Agent：负责搜集资料
分析师 Agent：负责结构化判断
编辑 Agent：负责生成报告
审稿 Agent：负责检查遗漏

但多 Agent 不天然更强。 很多时候，多个 Agent 只是把一个不稳定模型调用，变成了多个不稳定模型调用。

如果任务边界不清楚，多 Agent 会放大沟通成本。

OpenAI Agents SDK：适合快速做可观测 Agent

OpenAI Agents SDK 的核心抽象很直接：agent、tools、handoffs、guardrails、tracing。

它适合快速搭一个可运行、可追踪、可加安全边界的 Agent。

适合场景：

客服助手
内部运营工具
轻量工作流自动化
需要 tracing 和 guardrails 的应用

它的优势是贴近模型能力，心智负担小。 但如果你要做很复杂的跨系统编排，还是要结合自己的业务工作流和状态存储。

Microsoft Agent Framework：适合企业工作流和微软生态

微软这一侧，AutoGen 和 Semantic Kernel 的方向已经逐步汇合到 Microsoft Agent Framework。

它更适合企业应用： 有工作流、有持久化、有 hosting、有 Azure 集成，也更照顾 .NET 和企业开发习惯。

适合场景：

企业内部自动化
Microsoft 365 / Azure 生态
多 Agent 工作流
需要长期维护的业务系统

如果团队本来就是 C#、Azure、Microsoft 365 技术栈，这条路线会更顺。

Google ADK：适合 Google 生态里的 Agent 工程

Google ADK 官方定位是开放的 Agent 开发框架，强调开发、调试和部署可靠 Agent。

它对 Gemini 和 Google 生态更自然，也强调企业级部署。

适合场景：

Gemini 应用
Google Cloud 生态
企业 Agent 平台
需要本地开发到云部署的一体化链路

如果你的模型、数据和部署都在 Google Cloud 上，ADK 值得优先评估。

框架不是第一问题，边界才是

很多团队选 Agent 框架时，上来就问：

LangGraph、CrewAI、AutoGen、OpenAI Agents SDK 到底哪个好？

这个问题本身就有点危险。

更好的问法是：

我的 Agent 需要多长的任务链路？
工具有没有副作用？
失败后能不能恢复？
是否需要人工接管？
状态要不要持久化？
有没有评估集和回放能力？

如果只是内部问答助手，LlamaIndex 或简单 Tool Calling 可能就够。 如果是复杂流程编排，LangGraph 或 Microsoft Agent Framework 更合适。 如果是快速构建 OpenAI 生态 Agent，OpenAI Agents SDK 会更直接。 如果是角色协作型内容任务，CrewAI 的表达更自然。

先定业务边界，再选框架。不要反过来。

一个生产级 Agent 至少要有这些东西

真正准备上线时，我会看这张表。

如果这些都没有，Agent demo 再漂亮，也只是 demo。

面试里怎么讲 Agent

如果面试官问："你怎么理解 Agent？"

不要只答：

Agent 就是大模型加工具调用。

这个答案太浅。

可以这样答：

我理解的 Agent 是一个围绕目标运行的决策和执行循环。

它至少包含四个核心部分：模型负责理解和规划，工具负责和外部系统交互，状态负责记录任务进展，评估和观测负责判断执行是否成功。

和普通 ChatBot 相比，Agent 的关键不是多了一次工具调用，而是它能根据工具结果继续调整下一步动作。

工程落地时，我会重点关注工具权限、状态持久化、失败恢复、人工接管、trace 回放和 eval，而不是只看模型回答是否流畅。

如果再追问框架，可以补一句：

框架选择取决于任务形态。知识库型任务可以优先看 LlamaIndex；复杂状态流可以看 LangGraph；角色协作可以看 CrewAI；OpenAI 生态可以看 Agents SDK；微软企业生态可以看 Microsoft Agent Framework；Google Cloud 和 Gemini 生态可以看 ADK。

这比背概念更像做过工程。

结尾

回到开头那个问题：

一个能查订单、查物流、改地址的客服机器人，到底算不算 Agent？

我的判断是：

如果它只是按用户意图调用一次接口，它是 Tool Calling 应用。 如果它能围绕"解决用户订单问题"这个目标，自己规划步骤、调用工具、检查结果、处理失败、必要时转人工，并且整个过程可追踪、可评估、可回放，那它才更接近一个真正的 Agent。

Agent 的核心不是"更像人"。

而是：面对一个目标，它能稳定地想清楚、干下去、看结果、再调整。

能做到这四件事，框架才有意义。

往期精选

• 如何规避 RAG 系统中大模型的幻觉
• 通义灵码改名 Qoder CN，免费 AI 编程插件快没了
• 一句话生成技术图，这 3 个 GitHub Skill 太狠了
• 别再盲目上 Agent 了！大厂面试官最爱问的工程陷阱
• 90%的人只用了Superpowers 10%的能力，实战案例带你走通全流程

参考资料

• LangChain Agents 文档
• LlamaIndex Agents 文档
• CrewAI 官方文档
• OpenAI Agents SDK 文档
• OpenAI Agents SDK Tracing 文档
• Google Agent Development Kit 文档
• Microsoft Agent Framework 文档
• Microsoft Agent Framework 介绍