AI 智能体：从“会说话”到“会做事”的工程化跨越

一、智能体与 LLM 的分界线：谁在做决定

大语言模型生成情报，智能体应用这些情报来实现目标。这个区分看似细微，却决定了整个架构的设计方向。

当你问 ChatGPT“北京天气怎么样”，它可能编造一个答案。当你给一个智能体配上天气查询工具，它会判断“这个问题需要外部数据”，调用 API，拿到真实结果，再组织语言回复。LLM 负责理解和推理，工具负责与真实世界交互，循环让模型有机会看到自己行动的后果并修正。

微软的文档把智能体的核心组件拆成五个：基础模型提供推理能力、协调程序管理工作流和决策逻辑、知识定义智能体对环境的认知、技能和工具执行具体操作、自治逻辑决定如何解释信息和选择行动。这五个组件中，只有第一个是“模型公司提供”的，其余四个都是开发者需要设计和维护的。

二、少量代码：一个 Agent 的核心骨架

一个能查天气的智能体，核心逻辑可以压缩到三十行左右。下面这段 Python 代码展示了最关键的循环结构：

import json
from openai import OpenAI

client = OpenAI(api_key="...")

def get_weather(city: str) -> str:
    return {"北京": "晴，25℃", "上海": "多云，27℃"}.get(city, "暂无数据")

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "查询城市天气",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"]
        }
    }
}]

messages = [{"role": "user", "content": "北京今天天气怎么样？"}]

while True:
    resp = client.chat.completions.create(
        model="gpt-4o-mini", messages=messages, tools=tools
    )
    msg = resp.choices[0].message
    messages.append(msg)

    if not msg.tool_calls:
        print(msg.content)
        break

    for call in msg.tool_calls:
        args = json.loads(call.function.arguments)
        result = get_weather(args["city"])
        messages.append({
            "role": "tool",
            "tool_call_id": call.id,
            "content": result
        })

这段代码的关键不在语法，在循环的设计意图。模型第一次调用时，它选择调用 get_weather 工具，程序执行后把结果塞回 messages，模型第二次调用时看到了真实天气数据，才生成最终回复。这就是 ReAct 循环的最小实现：推理、行动、观察、再推理。

但这段代码离生产可用还有距离。它没有最大轮次限制，如果模型陷入“反复调用同一个工具”的循环，它会一直跑下去。它没有参数校验，模型可能编造一个不存在的城市名，工具内部需要兜底。它也没有日志，出了问题无法回溯是模型判断错了还是工具返回错了。

三、框架选型：2026 年的三条主要路径

经过 2024 到 2025 年的爆发期，智能体框架的格局已经收敛。2026 年被讨论最多的三角对比是 LangGraph、CrewAI 和 OpenAI Agents SDK。

LangGraph 的生产度最高。它把智能体建模为“图上的状态机”，每个节点是一个步骤，边定义流转条件。这个抽象带来的好处是可观测性：LangSmith 集成提供 checkpoint、时间旅行调试、人机协同审批，出问题时你能精确看到智能体在第几步、基于什么信息做了错误决策。代价是学习曲线最陡，简单任务用它会觉得“为了一个查天气的功能写了一百行配置”。

CrewAI 的上手速度最快。标准业务流程大约 20 行就能启动，它把智能体建模为“角色驱动的 crew”，一个 agent 写代码、另一个 agent 找 bug，通过角色描述和任务分配来协调。适合创业公司的 MVP 阶段，或者流程相对标准化的业务场景。但生产级 observability 和错误恢复能力弱于 LangGraph。

OpenAI Agents SDK 的心智模型最简洁，但锁定 OpenAI 模型。如果你的技术栈已经绑定 OpenAI，它的一等 tracing 和极低的上手门槛很有吸引力；如果需要多模型切换，它就不是一个选项。

另外两个值得留意的方向：TypeScript 项目看 Mastra，它原生支持 JS/TS 生态，和 Next.js/Vercel 的集成顺畅；类型安全敏感的 Python 项目看 Pydantic AI，用强类型约束工具参数和输出结构。

选型的实用判断：新项目、复杂控制流、需要长期维护，选 LangGraph；创业 MVP、业务流程为主、快速验证，选 CrewAI；已绑定 OpenAI 且不需要多模型，选 OpenAI Agents SDK。

四、工程化要补的五件事

Demo 跑通只是起点。从“能查天气”到“能在生产环境里稳定处理用户请求”，需要补的是下面这些。

工具设计。工具的名称和描述是模型做决策的唯一依据。如果工具叫 query、描述写“查询数据”，模型不知道什么时候该用它。好的工具描述应该包含触发场景、输入格式、返回内容的含义。参数数量控制在五个以内，用枚举而不是自由文本，减少模型的决策空间。

循环控制。必须设置最大轮次。模型可能因为工具返回不符合预期而反复重试，或者在两个工具之间来回横跳。超过轮次上限后，应该降级到人工处理或返回明确的失败信息，而不是让循环无限运行。

记忆管理。短期记忆就是 messages 列表，它让模型在多轮对话中保持上下文。但列表会越来越长，最终超出上下文窗口。生产环境需要做截断或摘要策略。长期记忆需要外部存储，比如把关键事实存到向量数据库，在需要时检索注入。

安全边界。涉及写操作（转账、删除、发送消息）的工具，必须有权限校验和人工确认环节。2026 年商业化智能体的标配是人机协同：关键决策点暂停，等待人类审批后再继续。这不是对模型能力的不信任，是对不可逆操作的必要约束。

评估与日志。记录每次工具调用的输入、输出、耗时和最终结果。没有日志，你无法判断一个失败的任务是模型选错了工具、参数传错了、还是工具本身返回了错误数据。

五、最常见的失败模式

智能体项目失败的原因，很少是“模型不够聪明”。更常见的情况是工具描述模糊导致模型调错，或者循环没有上限导致成本失控，或者关键操作没有人工审批导致事故。

一个值得警惕的信号是：你的智能体在测试环境表现良好，上线后却频繁出错。这通常意味着测试用例覆盖的是“顺利路径”，而真实用户的输入包含了大量边界情况——拼写错误、模糊指代、多意图混杂。解决办法不是换更强的模型，是在工具内部做输入校验和兜底，在循环中加入“如果连续两次工具调用返回错误，则向用户请求澄清”的逻辑。

另一个结构性问题是工具膨胀。当你给智能体挂载了二十个工具，模型的上下文窗口被工具定义占满，准确率反而下降。Google Cloud 的文档建议使用“渐进式披露”：只加载当前任务相关的工具，或者用多智能体委派，让协调者只看到子智能体，子智能体各自管理自己的工具集。