从“回答问题”到“完成任务”

假设你想整理一个文件夹里的会议记录，找出尚未完成的事项，按负责人生成清单。

直接使用大模型，你通常需要自己复制材料、分批提问，再把结果整理到文件里。模型负责理解和生成文字，你负责搬运信息、操作软件和检查进度。

AI Agent，也就是智能体，试图把这些步骤连接起来：读取文件，提取事项，发现信息缺失时继续查找，最后保存结果。

可以先把它理解为：以大模型为决策核心，能够调用工具、观察结果，并围绕目标继续行动的程序。

不过，给聊天机器人接一个查询接口，并不意味着它就拥有了完整的任务执行能力。判断重点是：它能否根据执行结果，决定下一步做什么。

为什么需要 Agent

大模型擅长处理语言，但模型生成的文字本身不会修改文件，也不会替你查询数据库。即使回答中写着“已经完成”，也不代表现实中的操作发生了。

工具让模型获得行动能力，程序则负责真正执行。例如，模型可以提出“读取这个文件”的请求，由程序检查参数后调用文件接口，再把内容交回模型。

Agent 适合处理路径不完全固定的任务。整理会议记录时，有的文档包含完整待办，有的只有讨论过程，还有的需要对照后续记录判断事项是否完成。系统需要根据材料调整处理方式。

但如果任务始终是“读取固定表格、计算总和、发送结果”，普通脚本或固定工作流往往更简单。只有当执行过程需要动态判断时，才值得引入更多自主决策。

一个 Agent 怎样工作

一个实用的 Agent 通常包含以下几部分：

  • 目标与约束：明确要交付什么，以及哪些操作不能做。
  • 大模型：理解当前情况，选择工具，或生成最终结果。
  • 工具：提供搜索、读取、计算、写入等具体能力。
  • 任务状态：记录已有信息、执行进度和工具返回结果。
  • 控制程序：校验请求、执行操作、处理异常，并决定何时停止。

这些部分组成一个循环：接收目标，选择行动，执行工具，观察结果，再决定下一步。

例如，模型先请求列出文件，再读取相关记录。如果工具返回“文件不存在”，下一步应该是检查路径或报告缺失，而不是假设读取成功，继续编写摘要。

规划不一定要一次完成。简单任务可以逐步推进，复杂任务可以先拆分，再根据反馈修正计划。无论采用哪种方式，都需要明确停止条件，例如目标已完成、缺少必要信息、达到调用次数上限。

所谓“记忆”，也不一定是复杂的长期存储。入门项目先保存本次任务的结构化状态即可，例如已处理文件、提取出的事项和错误列表。

小例子：把会议记录整理成待办

先做一个边界明确的小项目：读取指定目录中的会议记录，生成一份待办草稿，暂不自动发送。

只开放三个工具：列出文件、读取文件、保存草稿。模型不能任意执行系统命令，也不能访问目录之外的文件。

下面是简化的 Python 伪代码，重点是控制流程，不对应某个具体 SDK：

state = init_state(
    goal="整理会议记录，生成按负责人分组的待办草稿"
)

for _ in range(8):
    action = model_next_action(state, tool_specs)

    if action.type == "finish":
        if output_is_ready(state):
            break
        state.add_feedback("尚未生成有效草稿")
        continue

    if not allowed(action):
        state.add_feedback("工具或参数不符合限制")
        continue

    try:
        result = tools[action.name](**action.args)
    except ToolError as error:
        result = {"ok": False, "error": str(error)}

    state.add_tool_result(action, result)
else:
    report_incomplete(state)

这里，model_next_action 返回的是结构化请求，例如工具名和参数。控制程序检查它，再执行工具。工具规格需要说明用途、参数和返回格式。

allowed 应检查工具是否在白名单中、文件路径是否越界，以及写入位置是否符合要求。output_is_ready 则检查草稿是否成功保存、必要字段是否齐全。

同时要求每条待办附上来源文件，负责人或截止时间不明确时标注“待确认”。这样的交付物更容易核对，也能减少模型凭空补全信息的问题。

开发时容易踩的坑

把执行权完全交给模型。 模型可能选错工具或生成错误参数。权限控制、参数校验和执行次数限制应由程序落实。涉及付款、删除或对外发送的操作，还应设置人工确认。

把工具返回的内容当成指令。 文件或网页里可能包含“忽略之前要求”等文字。这些属于待处理的数据，不应获得修改系统规则的权限。仅靠一句提示词并不足以隔离风险，还需要限制工具能力。

任务失败后无休止重试。 重复调用可能增加费用，也可能造成重复写入。应设置超时、重试上限，并让有副作用的操作具备防重复机制。

只看最终回答。 “整理完成”不能证明文件存在，更不能证明内容准确。需要检查真实产物，保留工具调用日志，并用已知答案的样例测试遗漏、误判和异常情况。

一开始就设计多个 Agent。 多个角色之间的交接会增加状态管理和排错成本。先让一个 Agent 稳定完成一个小任务，再考虑是否确实需要拆分。

小结：先让一个任务可靠完成

从大模型到 Agent，关键变化是把语言理解接入实际操作，并建立“行动—反馈—调整”的循环。

入门时，选择一个范围小、结果容易检查的任务，提供少量工具，明确权限与停止条件，再验证交付物。衡量 Agent 的价值，应看它能否在可控成本和风险下稳定完成任务，而不是看它展示了多少步骤。

参考来源