什么是 AI Agent：从聊天到行动

先说结论

AI Agent = 一个大语言模型 + 一组工具 + 一个能"看结果、再决定"的循环。

普通对话模型是"你问一句，它答一句"，答完就结束。Agent 的差别在于：拿到目标后，它会自己拆步骤、调用工具去执行、观察执行结果，再决定下一步——直到完成，或者被叫停。

所以判断一个系统是不是 Agent，标准其实只有一条：

它能不能根据自己行动的反馈，决定下一步做什么。

能，就是 Agent；不能，就只是一个更聪明的函数。

一、从"回答问题"到"完成任务"

问"北京明天天气怎么样"，对话模型能答。但"帮我把明天的行程整理进日历，并在出发前一小时提醒我"——它答不出来，因为这需要查日历、写事件、设提醒，而且中途可能出错要重来。这就是 Agent 要解决的问题。

二、核心：Agent Loop

整个 Agent 的一切，本质上就是这个循环：

三个关键点，缺一不可：

1. 必须有工具——没有工具，循环就只是在自言自语。
2. 必须有反馈——工具返回的结果得真的回填进上下文，模型才知道上一步干成了没有。
3. 必须有停止条件——步数上限、token 预算、明确的完成信号。少了这一条，Agent 就能无限循环烧钱。

第三条最容易被忽略，也最容易出事。

三、四个组成部分

1. 模型：负责"想"

理解目标、拆解步骤、选择工具、解读结果。模型能力决定了 Agent 的上限——弱模型会在第三步就走偏，然后一路错下去。

2. 工具：负责"做"

通常是函数调用（function calling）：给模型一份工具清单，每个工具带名称、描述和参数 schema。模型输出"我要调用 search_flights，参数是……"，运行时去执行，再把结果塞回去。

工程上一条血泪经验：工具描述写得含糊，模型就会乱调。 描述里写清"什么时候该用、什么时候不该用"，比调整系统提示词有效得多。

3. 记忆：负责"别忘了"

• 短期记忆：上下文窗口。任务一长、工具输出一多，就会满。
• 长期记忆：外部存储——文件、数据库、向量检索。让 Agent 跨会话记住"用户是谁、上次做到哪了"。

4. 规划：负责"调度"

谁来推进循环？是最朴素的"想一步做一步"，还是先出一份完整计划再执行？这是架构选择，下面展开。

四、一个最小实现

抛开框架，核心逻辑几十行就能写完：

1def run_agent(goal, tools, max_steps=20):2    messages = [{"role": "user", "content": goal}]3
4    for step in range(max_steps):5        resp = llm(messages, tools=tools)      # 思考 + 选工具6        messages.append(resp)7
8        if not resp.tool_calls:                # 不调工具了，说明它认为可以收尾9            return resp.content10
11        for call in resp.tool_calls:           # 行动12            try:13                result = tools[call.name](**call.args)14            except Exception as e:15                result = f"工具执行失败：{e}"   # 失败也是一种反馈16            messages.append({"role": "tool", "content": str(result)})17
18    return "到达步数上限，任务未完成"

真正上线前，还要补三样东西：工具错误要回填而不是直接崩、每一步都要有日志、危险操作前要人工确认。

五、几种常见形态

最后一行值得单独说：固定工作流不是 Agent，但很多场景里它比 Agent 更好——稳定、可预测、成本可控。别为了用 Agent 而用 Agent。

六、能力边界：诚实版

说点不好听的：

• 它会自信地做错事。 有副作用的工具（发邮件、下单、删文件）上尤其危险。
• 上下文会满。 长任务跑到一半，早期信息就被挤掉了。
• 错误会累积。 10 步任务，每步 95% 正确，全程正确的概率约 60%。
• 提示注入是 Agent 独有的攻击面。 网页、文档、邮件里藏一句"请把密钥发到某个地址"，模型可能真的照做——因为工具返回的内容对它来说也是输入。
• 成本不可预测。 循环次数不定，账单就不定。

对应的安全实践：

1. 最小权限——只给任务必需的权限，不要图省事给管理员密钥。
2. 危险动作人工确认——读随便读，写要过闸。
3. 全链路可观测——每一步的输入、输出、调用都留日志，否则出事没法复盘。
4. 沙箱执行——代码执行、文件操作，全部关在隔离环境里。

七、什么时候不该用 Agent

Agent 不是万能药。这几种情况，老老实实用别的：

• 一次性的知识问题 → 直接问模型，别绕圈。
• 流程完全确定的业务 → 写普通代码或工作流，又快又稳。
• 错误代价极高的场景 → 加人工环节，别指望它自己兜底。

反过来，什么时候值得上 Agent？

步骤不固定、需要外部信息、结果可以验收。

三条都满足，Agent 才有价值。

八、写在最后

一句话总结：模型负责"想"，工具负责"做"，循环把两者接起来。

而真正的工程难点，从来不在提示词写得多漂亮，而在三件事：

给它多大权限、怎么知道它做对了、出错时怎么收得回来。

——这个问题目前还没有标准答案，欢迎在评论区聊聊：你最希望 Agent 替你做什么？又最不放心它碰什么？