企业官网建设流程全解析

我做了快两年的 Agent 工程，有个现象印象特别深：几乎每个团队在第一个 Agent Demo 跑通的时候，都会产生一种“这事已经成了”的错觉。Demo 里让模型搜个资料、写个周报、生成一段代码，单次调用，效果惊艳。可一旦把任务从“回答一个问题”变成“在真实系统里完成一件事情”——比如让它自己调研竞品、分析数据、再汇总成一份报告——崩盘往往就发生在这个节点。于是大家开始拼命调 prompt、换更大的模型，结果发现还是不解决问题。

干到后来我才慢慢想明白一件事：当 AI Agent 从单次回答走向长任务执行，真正发生变化的不只是模型的复杂程度，而是整个系统的性质。单次提问解决的是“聪明不聪明”的问题，长任务执行解决的是“可不可靠”的问题。“可靠”从来不是模型单方面能给的，它需要外面那一圈系统工程来兜底。这篇东西我想系统聊一聊：长任务执行里的工程工作到底发生在哪里，哪些环节是决定成败的关键，以及我在真实项目里踩过的坑和最后沉淀下来的做法。适合正在搭 Agent 系统、或者刚把 Demo 跑通正准备往生产方向推的工程师看。

1. 被 Demo 掩盖的真相：短任务与长任务的本质差异

1.1 短任务的成功本质上是一种“一次性成功”

先别急着上架构，我们得先搞清楚一件事：为什么单次问答的 Demo 总是给人很大的信心？

单轮问答的本质是“给定一段上下文，生成下一段文本”。模型在这一步里只需要对当前输入做局部回应，它不需要对前面说过的话负责，不需要维护任何跨步骤的状态，更不需要在多种外部反馈之间做协调。你在 Demo 里让它写周报，它会写；让它翻译一段话，它会翻；让它总结一篇文章，它总结得比实习生还快。这种“局部正确性”极大程度地掩盖了系统性的问题。

而长任务执行是另一回事。同样一个模型，放到一个需要调研三个竞品、阅读二十篇资料、交叉验证数据、最后输出分析报告的任务里，它会在某个中间步骤突然“忘了”最初的目标，或者把第一步的错误结论当成事实带进后面的推理，或者在某个工具返回异常之后开始原地打转。你让同一个模型跑十次，十次的结果和路径可能都不一样，但你很难定位是哪一环出了问题。

1.2 长任务真正改变的维度：从“生成”到“行动”

长任务执行把问题的性质从“生成”变成了“在环境中行动”。模型需要在多个步骤之间保持目标一致性，需要调用外部工具获取真实世界反馈，需要接受中间结果来不断修正后续决策，还需要在信息不完整的情况下做出下一步的取舍。这时，模型的单步能力只是基础条件，系统能不能把步骤串起来、把状态留住、把错误拦下来，才是决定成败的关键。

我在项目里看到的最典型的现象是：同样的任务、同样的任务描述，换成不同模型来跑，成功率差得很多；但哪怕是同一个模型，在不同工程实现下跑，稳定性也能差出一大截。这说明什么？说明长任务的瓶颈往往不在模型本身，而在工程侧的配合。

下面这张表是我在不同项目里总结的短任务与长任务的差异，它是我判断该不该用 Agent 的一个起点：

2. 记忆与上下文：长任务 Agent 的第一块基石

2.1 上下文窗口不是记忆

很多人在设计长任务 Agent 时，第一个犯的错误就是“把上下文窗口当成记忆”。上下文窗口是一个物理上限，模型只能看到窗口内的 token，超过的部分会随着长度增加而产生注意力衰减，严重的甚至直接被截断。长任务执行里，每调一次外部工具，返回一堆文本，立刻就会挤占上下文空间。几十步下来，最初的任务目标可能已经被挤到模型的注意力之外了。

我实际做项目时发现，“模型跑偏”很多时候不是模型不行，而是任务目标从上下文里被挤出去了。比如让 Agent 先调研市场、再写方案，它可能做到第 15 步的时候开始纠结某个竞品的细节，完全忘了自己最终要交的是一份“可以执行的市场进入策略”。这不是模型能力问题，这是上下文管理的问题。

2.2 一个可落地的记忆分层设计

既然上下文窗口不是记忆，那我们就得自己搭一套记忆系统。我的做法是分四层，每层解决不同的问题：

• 目标层：固定放在系统提示词里，包含任务目标、约束条件、验收标准。这层信息不可压缩、不能被挤掉，我通常会写一段“目标锚定”文本，每次请求都注入。
• 轨迹层：保留最近 N 步的完整记录，超过 N 步之后的内容做摘要压缩。这层解决的是“模型需要知道它刚才做了什么”的问题。
• 事实层：任务过程中积累的结构化事实，比如调研到的竞品价格、用户反馈、关键时间点，统一整理成结构化对象，需要的时候再注入，而不是全部堆在上下文里。
• 外部记忆：存在向量库或数据库里，跨会话复用，比如用户的长期偏好、历史任务结果，需要时检索出来。

下面是一个简化但能落地的记忆结构示例：

@dataclass class AgentMemory: goal: str # 目标层，不可压缩 trajectory: deque[StepRecord] # 轨迹层，保留最近 N 步 facts: dict[str, Any] # 事实层，结构化事实 external_db: VectorStore # 外部记忆 def build_context(self, max_tokens: int) -> str: # 组合目标 + 最近轨迹 + 需要的事实 + 检索的外部信息 context_parts = [self.goal] for record in list(self.trajectory)[-self.recent_steps:]: context_parts.append(record.summarized()) # 动态注入与当前子任务相关的事实 relevant_facts = self.get_relevant_facts() context_parts.append(relevant_facts) return truncate_to_limit("\n".join(context_parts), max_tokens)

这套结构的关键是：目标层永远在，轨迹层保留最近几步的完整细节，事实层按需注入，外部记忆靠检索。这样处理下来，长任务里最常出现的“任务目标丢失”问题基本被遏制住了。

2.3 摘要压缩的取舍逻辑

长任务的 token 管理不能靠简单截断，因为截断会丢失关键信息。我的做法是分层摘要：每个子任务完成后，立即让模型生成一段摘要，原始内容归档到外部存储，摘要留在轨迹层。下个子任务开始时，模型能看到前一个任务的摘要，但不必看全部过程细节。

团队里常说一个比喻：Agent 不能当金鱼，只有三秒记忆；但也不能背着一座图书馆跑路。记忆管理的本质是在信息完整性和上下文容量之间做取舍。摘要压缩就是把最近的过程信息压成“够用”的状态，既不丢失任务脉络，又不把上下文塞爆。

3. 从临场发挥到状态机：规划与执行的工程化拆解

3.1 两种主流范式的取舍

在讨论 Agent 的执行架构时，绕不开两种范式：先规划再执行（Plan-and-Execute）和边执行边规划（ReAct 风格）。

先规划再执行的好处是全局可控、成本可预估。模型先输出完整步骤，然后按步执行，工程侧可以提前看到整个执行路径，也方便做预算和监控。坏处是，任务越复杂，中间遇到意外就越容易让整个计划作废，重新规划的成本很高。

边执行边规划则相反，每走一步观察结果再决定下一步，灵活性很强，能在不确定性高的场景里随机应变。但代价是容易钻牛角尖：模型可能会因为某个工具返回了不预期结果而反复重试同一个动作，也容易在分支任务里越走越偏，token 消耗不可控。

3.2 工程侧最大的心得：显式状态机

这两种范式我都在项目里试过，最后的结论是：都不应该让模型“自由发挥”。工程落地最好的方式，是把整个 Agent 执行过程建模成显式的任务状态机，模型只是状态机里的决策者，而不是流程本身。

我会把任务状态定义成一组有限的、明确的状态，并在每个状态之间定义清晰的转移条件：

from enum import Enum class AgentState(str, Enum): PENDING = "pending" # 待执行 RUNNING = "running" # 执行中 TOOL_CALLING = "tool_calling" # 调用工具 VERIFYING = "verifying" # 验证中间结果 COMPLETED = "completed" # 任务完成 FAILED = "failed" # 任务失败

每一步执行流程是：状态从 PENDING 进入 RUNNING，模型决定要不要调用工具；调用时进入 TOOL_CALLING，等工具返回结果后进入 VERIFYING 做一致性检查；检查通过则继续下一步，不通过则回退；全部步骤完成进入 COMPLETED，出错且无法恢复则进入 FAILED。

为什么非要用显式状态机？因为状态机带来三个直接收益：可恢复，任务状态可以被持久化，崩溃后能从最近状态继续跑；可观测，每一步处于什么状态一目了然，排查问题方便；可控，可以对不同状态施加不同的重试策略和 token 预算，技术上能拦住模型在某个分支里无限循环。

3.3 状态流转与兜底规则

实际操作里，我会给状态流转配一套兜底规则。比如 TOOL_CALLING 状态下，如果工具连续返回错误，我允许模型在同一子任务里重试两次，但超过两次就必须进入 VERIFYING 重新评估方案，而不是继续硬试。再比如 RUNNING 状态下一旦发现上下文占用率超过 70%，就强制触发摘要压缩，把旧的轨迹层信息归档。

这套设计相当于给 Agent 套上了一个“轨道”，它可以在轨道里自由加速、减速、换道，但不能冲出轨道。长任务执行最怕的不是模型笨，而是模型在一个错误路径上越走越远，状态机是防止这个问题的最直接的工程手段。

4. 工具调用的可靠性工程：函数调用之外的一半工作量

4.1 工具层的“最后一公里”问题

把工具调用交给 Agent 之后，真正的麻烦才开始。模型输出参数格式不稳定、工具返回值与模型预期不一致、外部服务超时限流、API 字段变动、同一操作被重复执行导致幂等性问题……这些才是最消耗长任务工程精力的事情。

举一个我在项目里遇到的真实例子：让 Agent 调用一个用户信息查询接口，模型在生成参数时把可选的查询条件当成了必填项，还把一个枚举值拼错，结果工具直接报错。更糟的是，模型拿到报错信息后没有重新审视参数，而是重复提交了三次一模一样的请求。这个场景说明，工具层不能只做“把参数传进去、把结果返回来”这种薄封装，它需要一层完整的可靠性防护。

4.2 一个工具执行循环应该有的处理顺序

我在项目里沉淀了一套工具调用循环的处理顺序，每一步都很直接：

第一步，参数解析与校验。模型生成的参数是文本，不能直接信任。在传给真实接口之前，先用 JSON Schema 校验格式、检查必填项、规范枚举值。校验不通过就把明确的错误信息返回给模型，让它重写参数，而不是让真实接口去背锅。

第二步，执行与超时控制。每个工具都必须配独立的超时时间。我之前吃过亏：某个外部服务在高峰期响应特别慢，Agent 等不到结果就一直挂起，整个任务卡死。后来给每个工具设了明确的 timeout，宁可返回超时错误，也不能让任务无限阻塞。

第三步，结果归一化。外部接口的返回五花八门，有的返回 JSON，有的返回 HTML，有的直接在 message 里写一串错误码。我会把所有工具返回统一包一层结构，让模型不用猜：

ToolResult = { "ok": True, # 是否执行成功 "data": {...}, # 执行结果（如果 ok） "error": None, # 错误信息（如果不 ok） "truncated": False # 结果是否被截断 }

第四步，错误分类与重试决策。这里的关键是区分“可重试错误”和“不可重试错误”，不能一刀切。

4.3 重试语义的三种判断

• 可重试：瞬时错误，比如网络抖动、超时、限流。策略是退避重试，重试两到三次，每次加重退避。
• 不可重试的确定性错误：参数错误、用户权限不足、资源不存在。这种重试多少次都一样，正确做法是让模型修改行动方案，而不是继续重复调用。
• 需人工接管：外部服务长时间不可用、涉及跨团队权限审批、存在资金或安全影响的操作。这种直接标记为需要人工介入，不要在 Agent 内部死循环。

把这个分类内置到工具协议之后，长任务的成功率会有一个非常明显的提升。原因很简单：模型在有明确错误分类的情况下，更容易做出“换参数”“换工具”“终止任务”这些理性决策，而不是在同一个坑里反复横跳。

5. 让长任务自己兜底：错误恢复与检查点设计

5.1 高发故障与恢复策略

长任务在执行过程中一定会遇到各种故障。我梳理过项目里出现频率最高的几类错误，以及对应的恢复策略：

5.2 检查点：长任务不再“一崩全崩”

长任务执行的另一个关键设计是检查点。一个跑 30 分钟的任务，如果中途因为某个工具临时故障崩溃，然后从头开始跑，这在工程上完全不可接受。所以我把任务状态做了持久化，每一步执行完都写一次检查点，包含当前状态、已完成步骤、已收集的事实、还有多步的轨迹摘要。

{ "task_id": "task_001", "state": "VERIFYING", "current_step": 12, "completed_steps": [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11], "facts": { "competitor_a_price": 99, "competitor_b_launch_date": "2025-03-15" }, "trajectory_summary": "... 前序步骤的摘要 ..." }

有了检查点，Agent 崩溃或者上下文耗尽之后，可以从最近的位置恢复，而不是回到起点。恢复策略我倾向用“最后有效步回退”：检查点记录的是上一步验证过的状态，恢复时从那个状态重跑当前子任务，而不是直接跳到下一步。

5.3 允许模型说“我不行”

这个看起来很简单，但很多团队在设计 prompt 时都漏掉了：给模型一条体面的退出路径。

我在系统提示词里明确加了这样一条规则：“如果当前信息不足，或已多次尝试仍无法修正错误，请输出 TASK_FAILED，并附上已完成部分和无法继续完成的原因。”刚开始我担心加了这条会让模型轻易放弃，实际用下来发现恰恰相反：给了退出路径之后，模型反而不怎么硬编了。因为它在逻辑上“知道”自己可以不完成，就不需要用幻觉来凑一个假结果。

对长任务工程来说，承认失败不是坏事。一个诚实的 TASK_FAILED，配合已完成的中间成果和失败原因，比一份包装得光鲜但内容全错的报告有价值得多。失败信息让后续的人工接管有了清晰的交接点。

6. 长任务的可观测性：追踪、评估与成本

6.1 缺少可观测性会让长任务变成黑盒

长任务执行一旦跑起来，如果看不见中间过程，排查问题会变得非常痛苦。我之前经历过一次惨痛教训：任务失败了，模型给的结果看起来“写得挺好”，但整体都是基于一个错误的中间数据展开的。当时系统没有任何轨迹记录，我根本不知道哪一步开始出错，只能重新跑一遍碰运气。

这个教训之后我定了一个原则：长任务系统里，每个决策点都必须可见。模型做了什么判断、调用了什么工具、输入和输出是什么、花了多少 token、用了多长时间，全部要留痕。

6.2 全链路日志字段设计

我给日志设计了一套统一结构，每次模型调用和工具调用都按这个格式记录：

{ "task_id": "task_001", "step": 12, "state": "TOOL_CALLING", "input_summary": "查询竞品A的最新定价", "model_output": "调用get_product_price(product_id='A')", "tool_name": "get_product_price", "tool_args": {"product_id": "A"}, "tool_result_ok": true, "tool_result_truncated": false, "error_info": null, "token_usage": 1536, "latency_ms": 2340 }

这份日志既是我调试 Agent 的排障工具，也是后续评估 Agent 行为的重要依据。没有这些结构化的记录，所谓“优化 Agent”可能只是凭感觉调 prompt，有了日志，你才能定位到具体是哪一步出了问题、哪个工具最不稳定、哪类错误最常发生。

6.3 分阶段评估，不要只看最终结果

长任务是开放式的过程，它不像机器翻译或文本分类那样有一个参考答案可以比对。所以我的建议是把长任务拆成多个验收点，每个阶段先做“步级验收”，通过之后再进入下一阶段。

步级验收的意思是，每个子任务完成时，先拿这个子任务的预期结果做一次检查。比如“调研竞品价格”这个子任务，验收标准是“拿到三个竞品的价格数据，并且来源可追溯”。如果步级验收不通过，就地重试或调整，而不是等到整个任务跑完才发现问题。

除了步级通过率，我还会盯这几个过程指标：

6.4 成本是长任务工程里最现实的约束

长任务跑起来很容易让人忽略一个事实：token 消耗是线性累积，甚至是指数累积的。一个 50 步的任务，每步平均消耗几千 token，跑 5 次迭代就是几十万 token。如果都用大模型来跑，成本会让你怀疑人生。

我的做法是分级：低成本的小任务和中间步骤用轻量模型，只在关键判断点和复杂决策时切换到更强的模型。同时给任务设置 token 预算，预算用尽就先停下来评估进度。另外，对重复的工具调用结果做缓存，同样的查询在任务周期内直接复用结果，能省掉很大一部分 token 开销。

7. 边界判断：什么任务值得做成 Agent，什么不值得

7.1 不适合做长任务 Agent 的典型画像

老实说，不是所有任务都适合做成 Agent。我见过不少人把简单问题复杂化，最后的系统又贵又难维护。

不适合的典型画像有几类。一种是本来一次 API 调用就能解决的问题，硬写成几十步的 Agent 流程，纯粹增加失败概率。另一种是需要人类审美判断、战略权衡的高价值决策场景，Agent 可以做材料收集和初步分析，但让它拍板就非常危险。还有一种是外部依赖很脆的场景，工具动不动就挂，又没有兜底机制，这种情况下 Agent 跑得越久，出错的概率就越大。

7.2 适合长任务 Agent 的特征

反之，适合长任务 Agent 的任务通常具备这几个特征：多步骤、需要外部信息、中间结果会影响后续方向、流程相对标准化、有明确的完成标准、可以容忍一定失败率并且有人工兜底。

我常用的判断方法是把任务拆成三段看：信息获取段、决策段、动作段。如果三段里只有一段需要模型判断，别做长任务 Agent，用一个流程编排脚本就够了。如果三段都需要模型的推理能力，才值得投入做 Agent。

我最真实的建议是：为 Agent 而 Agent 是最烧钱的坑。先判断任务复杂度，再决定要不要上长任务架构。

最后分享一点我在实际项目里的体会。很多团队在 Agent 上踩坑，最深的坑不是模型不够强，而是把模型当成了整个世界，觉得换一个更聪明的模型就万事大吉，把系统工程当成了可有可无的部分。但长任务执行这件事，模型只是发动机，底盘、刹车、仪表盘以及副驾驶的判断逻辑，全都要工程来搭。如果你正准备把一个 Demo 推成生产级 Agent，我建议你先别急着调 prompt，先把状态机、检查点、日志追踪这三件事搭起来。这三件事做扎实之后，你会发现后面所有的迭代调整，都有了可以依靠的抓手。