如果你正准备往大模型方向转，《Agent上线前，最值得检查的不是模型参数》这类问题别只看热度。更重要的是判断自己该补哪块能力，以及怎么证明你真的会。

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

很多团队还在纠结是用 Qwen 还是 Llama 3，但在我的实际交付经验里，决定一个 Agent 能否从 Demo 走向生产环境的，往往不是那 0.5% 的推理准确率差异，而是权限隔离、全链路日志和可观测性。

最近面试了不少转做 Agentic AI 的开发者，发现一个通病：大家都会用 LangChain 或 LangGraph 跑通一个简单的“查询天气+发邮件”的流程，但一旦涉及多步任务规划、复杂工具调用时的状态管理，或者失败后的重试机制，系统就崩了。

Agent 的本质不是“更聪明的聊天机器人”，而是一个带有副作用的执行体。今天我们就抛开那些高大上的概念，从真正跑起来的角度，拆解 Agent 的核心三要素：规划、工具调用与记忆，并附上我在项目中验证过的实战建议。

目录

• Agent 的本质：从“生成”到“行动”
• 规划能力：别指望 LLM 一次性想清楚
• 工具调用：安全是第一位的
• 记忆系统：短期是上下文，长期是向量库
• 失败恢复：Agent 的韧性测试
• 总结：从“玩具”到“工具”的跨越

Agent 的本质：从“生成”到“行动”

以前的 NLP 任务是“理解并生成文本”，现在 Agent 的任务是“理解并改变世界”。

这意味着输入不再是单纯的 Prompt，输出也不再仅仅是字符串，而是一系列API 调用或数据库操作。这种转变带来了两个致命挑战：
1. 不确定性放大：LLM 会幻觉，如果幻觉导致它调用了错误的 API 参数，后果比生成一段错误文案严重得多。
2. 状态依赖：每一步行动的结果都是下一步行动的上下文。如果中间某一步失败，整个任务链必须能回滚或纠正。

因此，在简历或项目复盘中，如果你只说“我搭建了一个客服 Agent”，面试官只会觉得你是个调包侠。你需要强调的是：“我实现了一个具备容错能力的订单查询 Agent，通过结构化输出和事务回滚机制，将误操作率降低至 X%。”

规划能力：别指望 LLM 一次性想清楚

初学者最容易犯的错误是让 LLM 在一个 Prompt 里完成“分析用户意图 -> 选择工具 -> 构造参数 -> 执行 -> 解释结果”的所有步骤。这在工程上是灾难性的。

正确的做法是：思维链（Chain of Thought）必须被显式化为状态机。

在我负责的电商售后 Agent 项目中，我们并没有让模型直接决定“退款”还是“换货”，而是引入了一个中间层：Task Planner。它只负责拆解任务，不执行动作。

def plan_tasks(user_query: str, history: list) -> list[ToolCall]:
    """
    简单的规划器伪代码，演示如何将自然语言转化为工具调用列表
    """
    # 1. 提取关键实体
    entities = extract_entities(user_query)

    # 2. 基于历史对话判断当前状态
    intent = classify_intent(user_query, history)

    # 3. 生成工具调用序列
    # 注意：这里返回的是结构化数据，而非 JSON 字符串，方便后续校验
    if intent == "REFUND":
        return [
            ToolCall(name="get_order_status", args={"order_id": entities['id']}),
            ToolCall(name="check_refund_policy", args={"item": entities['product']})
        ]
    elif intent == "TRACK":
        return [
            ToolCall(name="query_logistics", args={"tracking_no": entities['tracking_no']})
        ]
    else:
        return [ToolCall(name="ask_human", args={"reason": "unclear_intent"})]

观点：规划的核心不是“智能”，而是“可控”。如果你的规划逻辑完全依赖 LLM 的动态生成，而没有预设好的状态跳转规则（State Transitions），在生产环境中你一定会失控。建议使用 LangGraph 或类似的状态图框架来显式定义节点和边。

工具调用：安全是第一位的

当 Agent 开始调用外部 API 时，它就获得了“写权限”。这时候，参数校验和权限最小化原则比 Prompt 工程重要一万倍。

很多开发者忽略了一点：LLM 输出的 JSON 格式可能不合法，或者包含恶意字段。例如，用户输入“帮我删除所有数据”，模型可能会尝试构造 {"action": "delete_all", "scope": "database"}。

在我们的实践中，任何工具调用都必须经过一个Guardrail 层：
1. Schema 强校验：使用 Pydantic 严格定义工具的输入输出结构。
2. 敏感操作二次确认：对于写操作（Delete/Update），强制要求人类审批或引入“Dry Run”模式。
3. 沙箱执行：工具本身不应直接连接生产数据库，而是通过中间件代理，记录所有调用流水。

记忆系统：短期是上下文，长期是向量库

记忆是 Agent 产生“连续性”错觉的关键，也是工程复杂度最高的部分。

• 短期记忆（Context Window）：不要把所有对话历史都塞进去。采用摘要式记忆，每隔 N 轮对话，对之前的内容进行压缩，只保留关键事实和情绪倾向。
• 长期记忆（Vector DB）：这是为了检索历史经验。注意，不要直接把聊天记录存入向量库，而是存储“事实条目”（Fact Entries）。例如，“用户张三喜欢咖啡口味偏苦”是一条事实，而“用户张三说今天好累”则可能只是瞬时情绪，无需永久记忆。

踩坑经验：初期我们直接将 RAG 结果拼接到 Prompt 中，导致上下文爆炸，延迟极高。后来改为“按需检索”：只在规划阶段检测到需要历史依据时，才去向量库检索 Top-K 相关内容，并经过重排序（Re-rank）后注入。

失败恢复：Agent 的韧性测试

Demo 里永远走的是理想路径。但在生产环境，网络超时、API 限流、LLM 幻觉导致参数错误是常态。

一个成熟的 Agent 必须具备自我修复能力：
1. 检测失败：工具返回非 200 状态码，或 LLM 生成的参数校验失败。
2. 原因分析：让 LLM 分析错误原因（是参数错了？还是服务挂了？）。
3. 重试策略：如果是参数错，修正参数重试；如果是服务挂，切换备用接口或降级为人工服务。

try:
    result = tool.execute(args)
except ValidationError as e:
    # 捕获参数错误，让 LLM 重新生成
    feedback = f"Error executing tool: {e}"
    plan = replan_from_feedback(plan, feedback)
    continue

except ServiceUnavailable:
    # 捕获系统错误，降级
    return fallback_human_handoff()

总结：从“玩具”到“工具”的跨越

如果你正在准备面试或构建自己的 Agent 项目，请记住以下几点取舍：

1. 不要过度追求模型的智商：在工程稳定性面前，Qwen-Max 和 Qwen-Plus 的差异远小于“有无日志追踪”的差异。
2. 可观测性是刚需：每一个 Agent 的决策路径、工具调用参数、响应时间都必须打上 Trace ID，存入 ELK 或 Prometheus。否则出了问题，你连 bug 在哪一步产生的都查不到。
3. 简历亮点：别只写“使用了 LangChain”。要写“设计了基于状态机的任务规划模块，实现了工具调用的自动重试与回滚，将复杂任务成功率从 60% 提升至 92%”。

Agent 的战场不在实验室，而在那些充满噪声、延迟和不确定的生产环境里。只有处理好权限、日志和容错，你的 Agent 才算真正“上线”了。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。