从聊天到委派：AI Agent 如何推进长期任务

目录

• [1. 引言](#1. 引言)
• [2. 从聊天到委派的范式转变](#2. 从聊天到委派的范式转变)
• [3. AI Agent 的核心能力](#3. AI Agent 的核心能力)
  • [3.1 任务规划](#3.1 任务规划)
  • [3.2 工具调用](#3.2 工具调用)
  • [3.3 记忆管理](#3.3 记忆管理)
  • [3.4 反思与纠错](#3.4 反思与纠错)
• [4. 长期任务的关键挑战](#4. 长期任务的关键挑战)
  • [4.1 上下文窗口限制](#4.1 上下文窗口限制)
  • [4.2 错误累积](#4.2 错误累积)
  • [4.3 目标漂移](#4.3 目标漂移)
  • [4.4 人机协作时机](#4.4 人机协作时机)
• [5. 架构设计](#5. 架构设计)
• [6. 一个可运行的示例](#6. 一个可运行的示例)
• [7. 从 Demo 到生产](#7. 从 Demo 到生产)
  • [7.1 可观测性](#7.1 可观测性)
  • [7.2 状态持久化](#7.2 状态持久化)
  • [7.3 安全与权限](#7.3 安全与权限)
  • [7.4 评估体系](#7.4 评估体系)
• [8. 总结](#8. 总结)

1. 引言

过去两年，我们熟悉的大模型交互方式大多停留在「一问一答」：用户输入 Prompt，模型返回一段文本，对话就此结束。这种模式擅长解释概念、改写文案、生成代码片段，却很难真正替用户「办成一件事」。

例如，你可以让 ChatGPT 解释「什么是 RAG」，它会给出一段结构清晰、语气专业的回答；但如果让它「调研五家云厂商的向量数据库，整理成对比表格，并输出选型建议」，传统聊天模式就会暴露出明显短板：它无法自主搜索资料、无法核对数据、无法把任务拆成多个步骤持续推进，更无法在遇到缺失信息时自我修正。它只是在「回答」，而不是在「执行」。

随着 LLM 能力的提升，业界开始把关注点转向 AI Agent（智能体）：模型不再只是被动地回答，而是能够规划目标、调用工具、观察反馈，并在较长时间跨度内持续执行任务。这正是「从聊天到委派」的关键跃迁------用户不再逐句指导模型，而是把目标委派给它，由它自己推进。

这一转变的意义在于：大模型正在从「对话窗口」走向「工作伙伴」。对话窗口的价值取决于你如何提问；而工作伙伴的价值，取决于它能否在无人盯守的情况下，把一件复杂的事可靠地做完。

本文将从范式转变、核心能力、长期任务面临的挑战与架构设计几个层面，探讨 AI Agent 如何从「会聊天」走向「能办事」。文中会用一个最小可运行的 Python Agent 示例贯穿说明，帮助你建立从概念到代码的完整认知。

2. 从聊天到委派的范式转变

要理解 Agent，首先要看清它与传统 Chatbot 的本质差异。传统 Chatbot 的工作流大致如下：

用户问题 → LLM 生成回答 → 返回给用户

整个过程是无状态的、单步的。所谓「无状态」，是指模型不会记住你上次问了什么，更不会主动去查询外部世界；所谓「单步」，是指一次请求只会产生一次输出，任务在模型返回答案的那一刻就结束了。

而 Agent 模式引入了「循环」：

用户目标 → 制定计划 → 执行动作 → 观察结果 → 判断是否完成
                ↑                              ↓
                └───────── 未完成则继续 ─────────┘

在这个循环里，模型不再只是「回答者」，而是扮演「决策者」：它要先拆解目标，再选择下一步动作；每执行一个动作，都要观察环境反馈；根据反馈判断任务是否完成，未完成就继续循环。

两者的差异可以归纳为下表：

维度	传统聊天	AI Agent
目标	回答问题	完成任务
状态	无状态	有状态、可追踪
工具	通常无	可调用 API、代码、浏览器
时长	单轮	多轮、甚至小时级
反馈	无需	根据环境反馈自我修正
错误处理	重新提问	自动重试、换策略
交付物	一段文本	报告、数据、执行结果

这里需要澄清一个常见误解：Agent 并不是「更强的模型」，而是一种「不同的系统形态」。即使底层模型能力完全相同，只要为它加上工具、记忆和循环控制，它就能从「回答者」转变为「执行者」。模型负责推理，系统负责编排。

委派的核心在于：把「怎么做」的决策权交给 Agent，只保留「做什么」和「验收标准」在用户手中。这要求 Agent 不仅能理解指令，还要能拆解步骤、选择工具并在出错时自我恢复。

值得注意的是，委派并不是「全有或全无」的选择。更成熟的做法是建立一张自主权光谱：

• 低自主权：Agent 只做信息收集和整理，所有关键决策由人做出。例如「把这三份 PDF 的关键数据提取成表格」。
• 中自主权：Agent 可以执行有明确规则的动作，但在高风险操作前必须征得人类同意。例如「自动回复客服工单，涉及退款时转人工」。
• 高自主权：Agent 在清晰边界内自主执行，人类只在任务结束时审阅结果。例如「每天凌晨抓取竞品价格并更新看板」。

理解这张光谱，是设计可靠 Agent 系统的前提：自主权越高，对规划、记忆、安全和可观测性的要求也越高。

3. AI Agent 的核心能力

一个可推进长期任务的 Agent，通常需要具备以下四类能力。它们并不是孤立的模块，而是一个相互配合的整体。

3.1 任务规划

面对「帮我调研三家竞争对手并输出对比报告」这类目标，Agent 需要将大目标拆解为可执行的子任务：

• 搜索竞争对手名称；
• 抓取官网与公开资料；
• 记录关键信息；
• 对比功能、定价、市场定位；
• 生成结构化报告。

拆解听起来简单，但真正困难的是处理依赖关系 和不确定性。比如「对比定价」依赖「抓取官网资料」；而「搜不到某家竞品的公开价格」又会打断后续步骤。好的规划不仅要列出步骤，还要考虑：

• 哪些子任务可以并行；
• 哪些子任务必须先完成；
• 缺失信息时可以如何降级；
• 什么条件下任务算「完成」。

常见的规划策略包括：

• ReAct（推理 + 行动）：每一步都让模型先推理再行动，适合目标相对模糊、需要边走边看的任务；
• Plan-and-Execute（先规划后执行）：先一次性制定完整计划，再逐步执行，适合路径比较清晰的任务；
• Tree of Thoughts（思维树）：对多个候选方案并行探索，再选择最优路径，适合决策空间较大的复杂任务。

实际系统中，往往不是二选一，而是分层规划：高层做粗粒度的目标分解，低层用 ReAct 循环处理具体的执行细节。例如「写行业周报」可以先规划「搜索 → 整理 → 成稿」，而「搜索」这一步内部又可能经历多次「换关键词 → 看结果 → 再搜索」的短循环。

3.2 工具调用

Agent 的能力边界很大程度上取决于它所能调用的工具。典型的工具有：

• 搜索工具（如搜索引擎、向量检索）；
• 代码执行器（Python / Shell）；
• 浏览器自动化工具；
• 内部 API（CRM、数据库、日历）。

工具的本质是让模型从「语言空间」走向「行动空间」。模型可以写出优美的 SQL，但如果不能真正连上数据库，它就无法回答「我们上个月流失了多少高价值客户」；模型可以给出网站抓取的思路，但如果不能真的启动浏览器，它就无法拿到页面上的实时数据。

Function Calling 是当前最主流的接入方式：将工具以 JSON Schema 的形式暴露给模型，由模型决定何时调用、传什么参数。一个典型的工具定义会包含名称、描述和参数说明：

{
  "name": "search",
  "description": "搜索互联网并返回结果摘要",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "搜索关键词"
      }
    },
    "required": ["query"]
  }
}

在工程实践中，工具设计有几个值得注意的点：

• 描述要精确：模型是「读描述」来决定要不要调用工具的，含糊的描述会导致误调用或漏调用；
• 参数要克制：一次暴露太多参数会让模型难以选择，必要时可以拆分多个工具；
• 文档要示例化：在描述里给出常见调用场景，比单纯列字段更有效；
• 错误要可读：工具执行失败时，返回给模型的错误信息应当包含「为什么会失败」以及「可以怎么调整」，而不是只抛出一串堆栈。

随着生态发展，MCP（Model Context Protocol） 等标准化协议也开始出现，让工具以统一接口接入 Agent，减少重复开发。

3.3 记忆管理

长期任务离不开记忆。记忆解决了「模型每次请求都是失忆的」这个根本问题：

• 短期记忆：当前任务上下文，受上下文窗口限制；
• 长期记忆：跨会话沉淀的用户偏好、历史决策、领域知识；
• 工作记忆：当前执行中的中间结果。

三者的分工可以用一个类比来理解：短期记忆是「桌面」，放的是正在处理的东西；工作记忆是「便签」，记的是刚算出来、马上要用的中间值；长期记忆是「档案柜」，存的是需要长期保留、跨任务复用的知识。

在实践中，很多复杂任务失败并不是因为模型「笨」，而是因为该记住的东西被挤出了上下文。比如，任务执行到第 20 步时，模型已经记不清第 2 步设定的输出格式要求。合理分层记忆可以避免「任务还没做完，上下文已经不够用」的窘境。

常见的工程方案包括：

• 用摘要压缩保存历史对话的关键结论；
• 用向量数据库存储可检索的长期知识；
• 用任务状态对象保存工作记忆，避免把所有中间变量都塞进对话。

3.4 反思与纠错

长期任务不可能一次成功。Agent 需要在每一步之后观察环境反馈，判断：

• 当前动作是否有效；
• 是否需要重试或换一种策略；
• 是否偏离了原始目标。

反思机制（Self-Reflection）是 Agent 区别于普通脚本的核心特征之一。普通脚本按固定流程运行，条件不符合时就直接报错；而 Agent 可以根据反馈调整自己的下一步行为。

反思的来源可以是多方面的：

• 模型自我评估：让模型对自己刚才的输出打分，判断是否真的回答了问题；
• 环境反馈：工具是否返回了有效结果、页面是否抓取成功、代码是否运行通过；
• 规则校验：输出是否满足预设格式、核心数据是否缺失。

思考清楚再行动，比盲目重试更高效。一个常见的实践是，在重试前让模型先总结「这次为什么失败」，再带着新的策略重新执行，而不是机械地把同样的动作再来一遍。

4. 长期任务的关键挑战

把执行周期拉长后，问题会成倍增加。下面是四类最值得警惕的挑战。

4.1 上下文窗口限制

复杂任务会产生大量中间信息：工具返回、错误日志、历史对话。当上下文耗尽时，Agent 可能遗忘早期目标或关键约束。

上下文窗口限制造成的失败通常具有「隐蔽性」：模型不会明确报错说「我忘了」，而是继续执行，只是行为逐渐偏离初衷。因此，不能等到上下文满了才处理，而要主动控制上下文增长。

应对方式：

• 对中间结果做摘要压缩，只保留「结论 + 关键数据」，而不是原始日志全量保留；
• 采用滑动窗口，始终保留最近 N 步的完整细节，更早的历史用摘要替代；
• 把重要信息（如任务目标、输出格式、用户偏好）固化为系统提示或任务契约，不随对话滚动而丢失。

4.2 错误累积

多步执行中，每一步的小偏差都可能在后续被放大。例如一次错误的数据提取，可能导致最终报告全部失真。这就是典型的「级联失败」：上游的一个小错误，在下游被当成事实继续加工。

应对方式：设置检查点（Checkpoint），在关键阶段校验中间产物，必要时触发回滚。具体可以包括：

• 每个子任务完成后，用规则或模型校验输出格式与关键字段；
• 将任务划分为可独立验证的阶段，避免一个错误污染全流程；
• 为不同阶段建立独立上下文，降低错误跨阶段传播的概率；
• 保存历史状态，允许在发现错误时回溯到上一个正确检查点。

4.3 目标漂移

Agent 在长时间运行中，可能被环境反馈带偏，逐渐偏离用户最初的目标。例如，原本任务是「调研 A 产品的定价」，执行过程中模型发现了大量关于 B 产品的信息，于是花大量步骤去分析 B，最终交付物偏离了用户需求。

目标漂移尤其容易出现在目标描述不够精确、任务步骤较多的时候。模型并不具备「用户意图」的天然感知，它只是在优化「下一步看起来合理」的动作。

应对方式：将初始目标固化为「任务契约」，在每个动作前用契约做对齐校验。任务契约至少应包括：最终要交付什么、交付物的格式、明确的边界条件、以及明确不该做的内容。同时定期在循环中用「我当前在做什么、是否符合最初目标」的问题检查对齐情况。

4.4 人机协作时机

长期任务不应完全脱离用户。有些节点（如大额支付、对外发送）需要人工确认。完全自主的 Agent 一旦执行了高风险错误操作，后果可能无法挽回。

应对方式 ：引入 Human-in-the-Loop 机制，在关键动作前暂停并等待授权。要落地这一机制，需要在系统层面预先定义「哪些动作需要审批」，例如：

• 涉及资金的操作，如支付、退款、降价；
• 对外发送的内容，如群发邮件、发布文章；
• 不可逆的操作，如删除数据、覆盖文件；
• 超出预算或超出预设边界的操作。

一个实用的实践是风险分级：低风险动作全自动，中风险动作记录后执行，高风险动作必须审批。人机协作的目标不是把人类变成「确认按钮」，而是让人类只在真正关键的时刻介入。

5. 架构设计

一个可落地的长期任务 Agent 架构如下。
#mermaid-svg-54F1n9ZhRPUw5RVp{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-54F1n9ZhRPUw5RVp .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-54F1n9ZhRPUw5RVp .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-54F1n9ZhRPUw5RVp .error-icon{fill:#552222;}#mermaid-svg-54F1n9ZhRPUw5RVp .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-54F1n9ZhRPUw5RVp .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-54F1n9ZhRPUw5RVp .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-54F1n9ZhRPUw5RVp .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-54F1n9ZhRPUw5RVp .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-54F1n9ZhRPUw5RVp .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-54F1n9ZhRPUw5RVp .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-54F1n9ZhRPUw5RVp .marker{fill:#333333;stroke:#333333;}#mermaid-svg-54F1n9ZhRPUw5RVp .marker.cross{stroke:#333333;}#mermaid-svg-54F1n9ZhRPUw5RVp svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-54F1n9ZhRPUw5RVp p{margin:0;}#mermaid-svg-54F1n9ZhRPUw5RVp .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-54F1n9ZhRPUw5RVp .cluster-label text{fill:#333;}#mermaid-svg-54F1n9ZhRPUw5RVp .cluster-label span{color:#333;}#mermaid-svg-54F1n9ZhRPUw5RVp .cluster-label span p{background-color:transparent;}#mermaid-svg-54F1n9ZhRPUw5RVp .label text,#mermaid-svg-54F1n9ZhRPUw5RVp span{fill:#333;color:#333;}#mermaid-svg-54F1n9ZhRPUw5RVp .node rect,#mermaid-svg-54F1n9ZhRPUw5RVp .node circle,#mermaid-svg-54F1n9ZhRPUw5RVp .node ellipse,#mermaid-svg-54F1n9ZhRPUw5RVp .node polygon,#mermaid-svg-54F1n9ZhRPUw5RVp .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-54F1n9ZhRPUw5RVp .rough-node .label text,#mermaid-svg-54F1n9ZhRPUw5RVp .node .label text,#mermaid-svg-54F1n9ZhRPUw5RVp .image-shape .label,#mermaid-svg-54F1n9ZhRPUw5RVp .icon-shape .label{text-anchor:middle;}#mermaid-svg-54F1n9ZhRPUw5RVp .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-54F1n9ZhRPUw5RVp .rough-node .label,#mermaid-svg-54F1n9ZhRPUw5RVp .node .label,#mermaid-svg-54F1n9ZhRPUw5RVp .image-shape .label,#mermaid-svg-54F1n9ZhRPUw5RVp .icon-shape .label{text-align:center;}#mermaid-svg-54F1n9ZhRPUw5RVp .node.clickable{cursor:pointer;}#mermaid-svg-54F1n9ZhRPUw5RVp .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-54F1n9ZhRPUw5RVp .arrowheadPath{fill:#333333;}#mermaid-svg-54F1n9ZhRPUw5RVp .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-54F1n9ZhRPUw5RVp .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-54F1n9ZhRPUw5RVp .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-54F1n9ZhRPUw5RVp .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-54F1n9ZhRPUw5RVp .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-54F1n9ZhRPUw5RVp .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-54F1n9ZhRPUw5RVp .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-54F1n9ZhRPUw5RVp .cluster text{fill:#333;}#mermaid-svg-54F1n9ZhRPUw5RVp .cluster span{color:#333;}#mermaid-svg-54F1n9ZhRPUw5RVp div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-54F1n9ZhRPUw5RVp .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-54F1n9ZhRPUw5RVp rect.text{fill:none;stroke-width:0;}#mermaid-svg-54F1n9ZhRPUw5RVp .icon-shape,#mermaid-svg-54F1n9ZhRPUw5RVp .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-54F1n9ZhRPUw5RVp .icon-shape p,#mermaid-svg-54F1n9ZhRPUw5RVp .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-54F1n9ZhRPUw5RVp .icon-shape .label rect,#mermaid-svg-54F1n9ZhRPUw5RVp .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-54F1n9ZhRPUw5RVp .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-54F1n9ZhRPUw5RVp .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-54F1n9ZhRPUw5RVp :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 否
是
用户委派目标
规划器 Planner
任务队列
执行器 Executor
工具调用 Tool
观察结果 Observation
是否完成?
记忆与反思
生成最终结果
返回用户

这张图描述的是核心循环：用户输入目标，规划器把目标拆成任务队列，执行器逐个执行，工具返回结果后进入观察与判断环节；未完成则经过记忆与反思后继续执行，完成则汇总结果返回用户。

关键模块职责：

• Planner：拆解目标、生成任务列表。它回答的问题是「要走到终点，需要完成哪些中间步骤」。
• Executor：逐个执行任务并选择工具。它回答的问题是「这一步应该调用什么、传什么参数」。
• Memory：保存短期与长期状态。它让 Agent 在不同步骤、不同会话之间保持连续性。
• Reflector：评估执行质量，决定是否重试或调整策略。它是质量闸门，也是纠错入口。
• Human Gate：关键节点的人机确认。它在自主与可控之间划出安全边界。

除了这些核心模块，生产级系统通常还需要两个横切能力：

• 任务队列与状态机：任务不是简单的线性列表，而是一个带有「待执行 / 执行中 / 成功 / 失败 / 已回滚」状态的系统。状态机让每个任务的状态可被追踪、可被恢复。
• 事件日志：每一步决策、每次工具调用都产生事件。事件日志既服务于可观测性，也是后续审计、评估和优化的数据基础。

在设计架构时，可以把握一个原则：让「推理」和「执行」解耦。模型只负责推理和决策，系统负责调度、记录和约束。这样既能替换不同模型，也能在不影响推理逻辑的情况下调整执行细节。

6. 一个可运行的示例

下面用一个 Python 示例演示极简 Agent 循环：模型根据消息列表决定动作，循环执行直到任务结束。

# requirements: openai, dotenv
import os
import json
from openai import OpenAI

client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

第一段代码完成了客户端初始化：从环境变量读取 API Key，创建 OpenAI 客户端。下面定义工具列表 TOOLS，这里只定义了一个 search 函数：

TOOLS = [
    {
        "type": "function",
        "function": {
            "name": "search",
            "description": "搜索互联网并返回结果摘要",
            "parameters": {
                "type": "object",
                "properties": {
                    "query": {"type": "string", "description": "搜索关键词"}
                },
                "required": ["query"],
            },
        },
    }
]

这段定义明确告诉模型：你可以调用一个名为 search 的函数，它接收一个参数 query，用于搜索互联网。接下来是核心的 Agent 循环：

def fake_search(query: str) -> str:
    # 示例仅模拟真实搜索接口
    return f"关于「{query}」的搜索结果：暂无关键数据，请进一步细化关键词。"


def agent_loop(task: str, max_steps: int = 5):
    messages = [
        {"role": "system", "content": "你是一个 AI Agent，可以通过调用 search 工具完成任务。"},
        {"role": "user", "content": task},
    ]

    for step in range(max_steps):
        response = client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
            tools=TOOLS,
            tool_choice="auto",
        )
        message = response.choices[0].message

        # 模型决定不再调用工具，返回最终答案
        if message.tool_calls is None:
            return message.content

        messages.append(message)
        for tool_call in message.tool_calls:
            name = tool_call.function.name
            args = json.loads(tool_call.function.arguments)

            if name == "search":
                result = fake_search(args["query"])
                messages.append({
                    "role": "tool",
                    "tool_call_id": tool_call.id,
                    "content": result,
                })

    return "任务达到最大步数，仍未完成。"

这个循环体现了 Agent 的核心模式：每轮调用模型，若模型发起工具调用，就执行工具并把结果追加回消息列表，然后继续下一轮；若模型不再调用工具，说明它已经准备好了最终答案，直接返回。max_steps 则避免了循环无限进行下去。

最后是入口：

if __name__ == "__main__":
    result = agent_loop("帮我调研 LangGraph 相比 AutoGPT 的优势")
    print(result)

这个示例只有「搜索」一个工具，但已经体现了 Agent 的循环结构。真实系统中，只需扩展 TOOLS 与对应的工具实现，就能调用数据库、文件系统或内部服务。

如果想让这个示例更接近生产，还可以逐步加入：将中间状态持久化、在每步记录日志、加入工具执行失败的重试逻辑，以及为「是否完成」设置更严格的判断标准。这些正是下一节要讨论的内容。

7. 从 Demo 到生产

把 Agent 从演示推向生产，还需要补齐以下能力。这四项能力共同决定了一个 Agent 系统能否被真正「委派」而不出乱子。

7.1 可观测性

长期任务必须具备完整的执行轨迹。每一步的工具入参、返回结果、耗时、Token 用量都应记录，便于定位问题与评估成本。

可观测性不只是「打日志」，而是一套结构化的追踪体系：

• 轨迹（Trace）：记录一次任务的完整执行树，包含每一步的输入、输出、耗时时长；
• 指标（Metrics）：统计成功率、平均步数、工具调用次数、Token 消耗、成本等；
• 日志（Logs）：记录关键事件，尤其是工具错误和重试原因。

有了这些数据，当用户问「为什么任务没完成」时，你才能回答「第三步搜索超时，重试两次后降级跳过」。可观测性也是后续评估体系的数据基础。

7.2 状态持久化

进程可能中断。任务队列与中间状态需要落库，使 Agent 在重启后能从中断点继续，而不是从头再跑。

持久化至少需要覆盖三类内容：

• 任务与子任务状态：当前执行到哪一步、每一步是成功还是失败；
• 工作记忆和中间产物：已抓取的数据、已生成的草稿；
• 检查点快照：支持在出错时回滚到上一个稳定状态。

实现上，任务队列可以落关系库或消息队列，中间产物可以存对象存储，检查点可以用版本化的状态对象。另一个不可忽视的问题是幂等：同一个工具调用重放时不应产生重复副作用。

7.3 安全与权限

工具调用具有真实副作用。应当遵循最小权限原则，并对外部写操作设置审批闸门。

具体的安全实践包括：

• 最小权限：每个工具只授予完成任务所需的最小权限，避免一把钥匙开所有门；
• 审批闸门：对资金、外部发送、不可逆操作等高风险动作暂停并等待人工授权；
• 沙箱执行：代码执行器、浏览器等工具应运行在受限环境中，防止模型生成的内容影响宿主机；
• 敏感信息检测：在对外输出前，检查是否包含密钥、个人隐私等敏感数据；
• 操作审计：记录每次工具调用的执行者、时间、参数与结果，便于事后追溯。

安全是长期任务能否委派出去的前提。一个能自主打电话、发邮件、操作数据库的 Agent，一旦失控，破坏力远大于一个只会聊天的 Chatbot。

7.4 评估体系

「任务是否成功」需要有明确的评估标准，可以是：

• 结果是否通过自动校验；
• 是否满足用户预设的验收条件；
• 人工评分。

没有评估，长期任务的迭代就失去了方向。评估体系应当既包含终局评估 （最终交付物是否合格），也包含过程评估（中间步骤是否高效、是否无意义重试）。

实践中，比较务实的做法是从「最小可量化」开始：先记录一批真实任务，然后定义三到五个关键指标，例如任务完成率、工具调用成功率、平均完成步数、单任务成本、用户满意度。随着数据积累，再逐步细化评估维度，甚至用模型辅助打分。

8. 总结

AI Agent 正在把大模型从「对话窗口」推向「工作伙伴」。实现这一转变的关键，并非给模型套上更多提示词，而是构建一个具备规划、执行、记忆、反思和人机协作的闭环系统。

长期任务的推进，本质上是在对抗三个敌人：上下文有限、错误累积、目标漂移。谁能更好地管理状态、控制风险并保持对齐，谁就能让 Agent 真正值得被委派。

回顾前文的脉络，一条清晰的主线呼之欲出：从「回答问题」到「完成任务」转变，核心不是让模型更会说话，而是为它补上行动的闭环；而要让行动可靠，就必须在规划、记忆、安全、可观测性上投入同等精力。 一个只会调用工具却没有记忆的 Agent，会反复犯同样的错误；一个行动力很强却没有安全边界的 Agent，则可能造成超出预期的后果。

对开发者而言，当下最务实的路径是：从一个清晰的小任务开始，设计好工具接口与检查点，再逐步扩大任务范围与自动化程度。委派的前提，永远是信任；而信任，只能来自一次次可靠的完成。