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

不妨再追问几个问题：

当它查不到订单时，能否自动判断是参数缺失、接口故障，还是用户提问方式有误？调用改地址接口前，是否会先确认权限、地址格式、订单状态？修改完成后，能否验证结果，并在失败时切换另一种路径继续处理？

如果答案都是"不会"，那它更像一个"会调用工具的聊天机器人"，而非真正的智能体。

真正的 Agent，绝不只是会聊天或会调 API。会聊天、会调 API，都不算真正踏入 Agent 的门槛。能自主思考、独立执行、主动复盘，才算摸到门道。

Agent 到底是什么

一句话概括：它不是一次问答，而是一段持续的过程。

普通 LLM 应用通常是这样：

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

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

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

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, order_id, address):
    order = order_service.get_order(order_id)
    if order.user_id != user_id:
        raise PermissionError("订单不属于当前用户")
    if order.status not in ["CREATED", "PAID"]:
        raise ValueError("订单地址已不可更改")
    if not address_validator.is_valid(address):
        raise ValueError("无效地址")
    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=a vailable_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 的核心追求，从来不是"更像人"。

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

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

参考资料

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