企业官网建设流程全解析

让一个AI模型去写一段短文案，它通常表现很好；但如果你让它负责一个需要连续执行好几个小时、甚至跨天协作的完整工作流——比如收集一批竞品信息、阅读和筛选原始资料、整理成结构化文档、给出结论、生成图表，还要在过程中根据中间反馈调整方向——事情往往就开始失控。

我最近在看长时程AI任务评测时，这种感受特别明显。相关评测显示，当前顶尖模型在长时程任务上的表现，只有人类水平的 27.3%。这个数字要放在单项问答、代码生成或短文本概括里，很容易被当成一次糟糕的测试结果；但如果把它放回“长时程任务”这个场景里，它说的其实是另一件事：我们一直在用“短跑标准”训练和评价模型，却在越来越多的地方指望它们去跑“马拉松”。

这篇文章不做纯科普，也不只复述一个数字。我想从“为什么顶尖模型只有人类 27.3%”这个问题出发，聊一聊长时程任务评测到底是什么、为什么会测出这么低的分数，以及普通开发者和技术团队能从中得到哪些真正可用的改进思路。

1. 长时程任务，评测的不是“会不会”，而是“撑不撑得住”

1.1 从单轮问答到多步闭环：任务性质变了

传统的大模型评测，大多数是“给一个输入，看一个输出”。比如问模型一个常识问题，看回答对不对；给一段代码需求，看生成代码能不能编译通过；给一篇文章，让模型写摘要，再和参考答案对比得分。这类任务里，模型只需要一次推理，上下文是完整的，问题边界是清晰的，标准答案是确定的。这种评测能很好地反映模型的“单点智能”，但很难反映模型在真实工作流中的价值。

长时程任务不一样。它要求模型在一个相对宏大的目标下，连续完成多个不同环节的操作。这些环节之间往往还有依赖关系：第一步的输出是第二步的输入，第二步的结果会影响第三步的决策。整个任务跨度可能是几十分钟、几个小时，甚至需要跨天执行。模型必须在执行过程中记住早期的目标、约束和关键信息，在后续步骤中持续使用它们，同时还要处理新出现的信息、异常和干扰。

换句话说，长时程任务评测的并不是“模型懂不懂某个知识点”，而是“模型能不能像一个靠谱的项目执行者一样，从头到尾把一个多环节任务稳定地推进下来”。单点能力可以通过堆参数、堆数据快速提升；但“稳定地推进一个长流程”，考验的是规划、记忆、自我监控、错误恢复和状态管理，这些恰恰是当前模型最薄弱的环节。

1.2 长时程任务里的三类典型场景

如果要把长时程任务具体化，常见的场景大致可以分为三类。

第一类是信息收集与综合。比如让AI去为一个行业话题收集近一个月的动态，要求来源不少于十个，输出包括摘要、趋势判断和来源列表。这个任务看上去不难，但模型需要多次搜索、打开网页、判断内容相关性、去重、筛选，并在一段时间后把零散信息汇总成逻辑一致的报告。问题很容易出现在中间环节：搜索到结果后没有保存来源，阅读了几个页面后忘了最初的目标，或者被大量无关信息带偏方向。

第二类是多工具调用与状态管理。比如让AI操作一个自动化流程，需要调用搜索、数据库查询、文件读写、内容生成等多种工具，且每一步都要更新某个状态变量。这类任务里，模型不仅要理解每一步操作，还要维护一个不断变化的外部状态。常见的问题是工具返回格式不一致时，模型不会恢复，直接卡死或重复调用；或者更新了状态但在后续步骤中使用旧状态。

第三类是长篇幅内容生产。比如一口气写一份完整的产品方案，或者修改一个开源项目的多个文件。任务过程中需要保持整体风格一致、逻辑不矛盾，并且对前期已经写过的内容保持记忆。这里的难点不在于第一段怎么写，而在于写到第三部分时，模型是否还记得第一部分里的关键设定。

这些场景的共性是：完成度不只依赖“某一次生成能力”，而是依赖一整套连续决策和自我管理能力。所以评测长时程任务，本质上是在考验模型有没有“长期工作素养”。

2. 为什么顶尖模型只能拿到人类 27.3% 的水平

2.1 四个瓶颈：记忆衰减、错误累积、规划失效、状态恢复困难

如果只看单点能力，顶尖模型在绝大多数基准测试里都已经接近甚至超过人类平均水平。那为什么一到长时程任务，分数会掉到人类水平的 27.3%？从评测轨迹和工程经验看，问题主要出在四个地方。

记忆衰减是第一道坎。即使模型的上下文窗口足够大，在实际长任务中，早期信息也很容易被大量中间内容稀释。模型不是真的“忘记”了，而是在处理后续步骤时，没有把早期关键信息当作当前决策的约束条件。比如任务要求“只统计最近三个月的新闻”，模型可能在第五轮检索时开始关注半年以前的文章，然后把它们也写进报告。这类错误不是由于模型不懂时间过滤，而是因为长序列里对早期约束的注意力权重被分摊了。

错误累积更加致命。长时程任务通常有链路依赖，早期一个小错误不会立刻引起注意，但会被后续步骤当作既成事实继续加工。比如模型在第一步把某公司的名称理解错了，之后所有检索和总结都围绕这个错误名称展开，最终报告的核心结论也随之偏离。单步错误率可能只有几个百分点，但经过二十步、五十步的链路传递，最终出错的概率会迅速放大。

规划失效是另一个典型问题。模型在任务开头通常会列出一个看起来合理的步骤计划，但执行中一旦遇到计划外情况，比如某个检索接口返回超时，某个页面被验证码拦截，某个文件格式不符合预期，它就很难重新规划出替代路线。更常见的是，模型会尝试一遍遍重复同样失败的调用，而不是停下来反思“当前方式可能不对，需要换一条路”。这种缺乏弹性的行为，在短任务里很难暴露，在长任务里会严重浪费时间和资源。

状态恢复困难则是工程化落地的关键痛点。短任务中断后重跑一次没多大成本，但长时程任务如果执行到一半中断，理想情况应该能从断点恢复。模型在这方面的能力普遍偏弱，往往需要从头开始，或者只能恢复到很粗粒度的状态。评测中一旦加入“中途注入外部变化”或“强制中断后继续”这类操作，很多模型都会明显失分。

2.2 上下文窗口不是万能药

面对长时程任务，很多人第一反应是：把模型上下文窗口加大，把所有历史记录都塞进去，模型不就能记住一切了吗？这个思路在方向上是合理的，但远没有想象中那么简单。

上下文窗口扩大，只解决“装得下”的问题，没有解决“用得上”的问题。当上下文里包含几十页对话记录、工具调用日志、网页摘要和中间结果时，模型需要在海量信息中定位真正关键的条目。注意力机制在处理这类长序列时，依然容易被近期内容或显著性内容影响，导致早期关键约束被忽略。同时，更长的上下文意味着更高的推理成本和更长的首字延迟，如果在任务中频繁调用模型，开销会很快膨胀。

从工程实践看，依赖外部记忆和结构化状态管理，往往比单纯扩大上下文窗口更有效。比如在Agent系统中增加一个专门的状态存储，让模型定期把关键决策写入结构化文件；或者使用独立检索模块，在需要时把最相关的历史记录拉回上下文。这些手段是把长任务从“一口气记住所有事”变成“在需要时快速找到正确的事”，本质上是在补模型的记忆短板。

所以，27.3% 这个低分，并不能通过“换一个更大上下文窗口的模型”就自动解决。它反映的是一个系统性问题：模型自身在长流程中的信息管理能力还不够。

2.3 27.3% 不意味着模型“笨”，而是评测维度变了

看到 27.3% 这个数字时，不要马上得出结论说“顶尖模型不行”。要理解这个数字，需要分清评测维度变化。

传统AI评测衡量的是“知识密度”和“单步推理能力”，模型可以在几秒内完成一次高质量推理；而长时程任务评测更像是在考“项目管理能力”。人类做长任务时，会做规划、写备忘、定期检查进度、遇到问题主动调整策略，甚至会在关键节点停下来向同事确认。这些行为看似简单，背后是元认知能力——时刻意识到“我现在在哪里、我离目标还有多远、我该优先做什么”。

当前模型在元认知层面还很弱。它可以在单步内回答正确，但缺少一个稳定的“自我监控器”来评估当前状态是否有偏离目标的迹象。因此，模型在短任务里可以表现得像一个聪明的专家，到了长任务里却像一个容易分心、不会复盘、也不擅长从失败中学习的初级实习助理。

这不是说模型没有价值，而是说我们应该换个角度去看模型的能力边界。如果只做短时任务，短时基准就够了；如果部署到真实业务流里，长时程能力就必须单独评测、单独优化。

3. 长时程AI任务评测是怎么做出来的

3.1 评测任务设计：从提交到验收，要覆盖完整闭环

要设计一个好的长时程任务评测，核心不是“选一个很难的问题”，而是“把任务设计成一个需要多步执行、多步验证、最终交付完整结果的闭环”。

一个合格的长时程任务，至少要包含四个要素：

• 明确的任务目标：模型要交付什么，比如“生成一份XX行业近30天动态分析报告”。
• 初始状态：任务开始时提供什么资源、限制哪些条件，比如“只能使用给定的搜索接口，访问外部网站不能超过30次”。
• 过程约束：任务执行中必须经过哪些环节，比如“至少检索10个不同来源，保存每个来源的标题、链接、访问时间和摘要”。
• 验收标准：最终结果怎么判分，比如“信息覆盖度是否完整、来源是否有效、结论是否与数据一致、格式是否满足要求”。

评测任务不能设计成模型靠一次回答就能完成。如果任务太短、太直接，评测结果依然会退化成单点能力测试，失去长时程评测的意义。我见过一些早期评测任务，名义上叫“长时程”，实际只是把一个长问题丢给模型，让模型一次性生成答案。这种任务只能偶尔暴露模型对长输入的记忆问题，却测不出一个完整工作流的稳定性。

设计任务时，还需要注意难度梯度。建议一组任务里同时包含“中等长度、多个依赖步骤”和“超长周期、跨天执行、外部状态变化频繁”两种难度。这样既能测出模型在正常长流程里的表现，也能测出它在极端压力下的退化速度。

3.2 过程追踪与评分：结果正确不等于过程可靠

长时程任务评测最容易犯的错误，是只给最终结果打分。如果模型最终输出的报告看起来完整，但过程中忽略了很多关键步骤，或者多次绕弯路、大量无效调用之后才“蒙对”结果，这种表现不能在真实业务中被认可。

所以评测要同时关注两个维度：最终交付质量，以及执行过程质量。最终交付质量相对好打分，比如覆盖度、准确性、格式规范性；执行过程质量则需要记录完整轨迹，并统计多个指标。

一个可参考的评分维度表如下：

过程追踪需要依托评测平台。评测系统要记录模型每一次动作的输入输出、耗时、调用状态、重试次数，以及模型在每个时间节点的内部状态摘要。缺少过程记录，任何对模型“为什么失败”的分析都会变成猜测。

3.3 一个最小评测流程示例

如果只是个人或小团队想先尝试长时程评测，不需要一开始就搭一个大型平台，可以先做一个最小流程。

第一步，定义一个任务描述文件，包含目标、初始状态和验收标准。第二步，准备一个隔离的评测环境，尽量屏蔽外部不稳定因素，比如固定搜索接口的超时时间、设置权限范围。第三步，让模型以 Agent 方式运行，通过工具调用完成任务。第四步，用脚本记录每一步的轨迹和状态。第五步，人工或半自动方式对结果打分。

轨迹记录可以采用简单的 JSON 结构，例如：

{ "task_id": "research-report-001", "goal": "生成行业动态周报", "start_time": "2025-01-01T09:00:00Z", "steps": [ { "step": 1, "action": "search", "query": "AI agent trends 2025", "status": "success", "duration": 2.3, "result_summary": "返回10条结果" }, { "step": 2, "action": "open_url", "url": "https://example.com/report", "status": "failed", "error": "timeout", "duration": 8.1 } ], "final_output": "...", "score": { "completeness": 0.8, "efficiency": 0.6, "recovery": 0.4 } }

这只是一个通用示例结构，具体字段需要结合任务类型调整。跑评测前有几件事要先确认：模型版本、依赖包版本、可访问的API列表、网络权限、超时设置。否则很容易出现“昨天能跑通，今天全部失败”的情况，而且很难定位是模型的问题还是环境的问题。

注意：不要一上来就设计超长周期的任务。先让模型在一个小时内能跑完的任务上反复评测，确认评测环境稳定后再逐步拉长时间和复杂度。评测框架本身也需要被评测，否则数据不可信。

4. 普通开发者怎么把长时程评测用起来

4.1 不要只看最终分数，要拆解“在哪个阶段丢分”

长时程任务评测的价值，不在于一个最终百分比，而在于它能帮助我们发现模型到底在哪个环节掉链子。所以拿到评测结果后，不要只盯着 27.3% 这个数字叹气，应该把任务拆成阶段，统计每个阶段的完成率。

一个比较通用的拆法是把长任务分成六个阶段：理解需求、制定计划、执行步骤、检查结果、修正反馈、最终交付。可以先统计模型在六个阶段里的表现，看它是在计划阶段就偏离了目标，还是在执行阶段频繁出错，又或者是在最终交付前没有做质量检查。

从很多早期评测轨迹来看，模型通常在“执行步骤”和“修正反馈”两个阶段丢分最多。执行步骤阶段容易因为工具调用失败和单步错误累积而崩溃；修正反馈阶段则经常出现“模型已经知道结果有问题，但不知道怎么改”的情况。如果你在用长时程评测自己的Agent，可以按这个链路排查：

1. 先看轨迹，判断任务在哪一步断掉；
2. 再看输入状态，确认当时模型可用的上下文里是否包含关键信息；
3. 再看工具调用，确认是超时、格式错误、权限不足，还是工具返回了不可解析的数据；
4. 再看模型决策，检查它是否沿用了错误的中间结果；
5. 最后看任务设计，确认是不是验收标准不清晰或目标约束遗漏。

这条链路可以帮助你避免一上来就换模型或调参数。很多时候，问题根本不在模型推理能力，而在于缺失状态管理或工具调用过于脆弱。

4.2 用评测结果反推 Agent 设计：先控错误累积，再优化单步能力

长时程任务评测结果最直接的价值，是指导 Agent 系统设计。如果评测显示“模型在第三步之后开始出现明显偏离”，那么第一步要做的不是换更大的模型，而是减少错误累积的机会。

具体可以这么做：让每个工具调用都输出结构化结果，并且对结果做校验。比如要求返回 JSON，如果解析失败，则重试或标记为失败，而不是继续往下走。在关键步骤之间加入摘要节点，让模型每隔几步写一个“当前状态：已完成X，待办Y，不确定项Z”，这样即使早期信息被稀释，后续步骤也能从明确摘要中恢复。

还可以在关键位置设置人工确认点。比如在模型准备生成最终报告之前，要求它先列出报告大纲和数据来源，由人工确认后再继续。对于长时程任务，人工审核不是降低效率，而是防止模型把错误一路滚到最后。

强调一个原则：先控错误累积，再优化单步能力。很多团队会在模型单步准确率上花大量精力，但忽视了长任务中的状态管理。单步准确率从 99% 提到 99.5%，看起来很好；但如果每一步都允许少量误差传递，经过四十步后，最终结果可能仍然不可用。相反，通过结构化的中间状态和校验机制，即使单步能力一般，整体稳定性也会明显提升。

4.3 适合与不适合用长时程评测的场景

长时程任务评测不是万能的，它适合解决某些问题，但不适合作为所有场景的通用标准。

适合用长时程评测的场景至少包括：客服 Agent，需要多轮对话并持续跟踪用户问题；文档处理工作流，需要读取多个文件、生成报告、并多次更新；代码仓库级任务，需要理解多个文件并修改后跑测试；市场调研自动化，需要持续搜索、阅读、筛选并输出结论。这类场景的共同特点是：有明确的长期目标、需要多步工具调用、中间状态会影响最终结果。

不适合用长时程评测的场景则包括：单轮问答、单文件代码生成、短文本分类、简单内容续写。这些任务用常规基准测试更直接、更快、更便宜。另外，长时程评测成本较高，每次任务可能要执行几十次甚至上百次模型调用，不适合在开发调试阶段频繁跑。建议先在小规模手动任务上验证思路，再进入正式评测。

5. 从 27.3% 到可用的工程化路径

5.1 先跑通单次闭环，再扩展到跨天任务

看到“顶尖模型只有人类 27.3%”这个数字，很容易产生两种极端反应：要么认为长时程AI不可用，要么觉得只要继续堆算力就能解决。这两种反应都过于简单。

实际落地时，更应该先接受一个现实：当前模型在长时程任务上并不成熟，所以不能一上来就部署一个无人值守的完整工作流。推荐路径是先选一个最小任务闭环，人工控制每一步，让模型在短时间内跑通一次。这里的“跑通”不是指模型独立完美完成，而是指整个流程节点是通的，模型和工具之间的调用是顺畅的，中间状态是可记录的。跑通之后，再逐步增加任务步骤、引入更多不确定性、拉长执行时间。

举个例子，如果要做一个“自动竞品信息整理”Agent，可以先不要一上来让它自己从零规划，而是把任务流程拆成固定步骤：搜索指定关键词、读取前五条结果、提取摘要、保存到表格、生成简报。每一步单独测试，确认稳定后再串成完整流程。然后才允许模型在遇到异常时做小范围调整。只有在单次闭环已经稳定的情况下，才应该去挑战跨天任务。

这样做的好处是，可以把评测数据和问题定位精确到具体环节，而不是面对一个 27.3% 的模糊分数无从下手。

5.2 建立检查点、重试和人工审核机制

长时程任务要真正进入生产环境，不能只靠模型自身能力，工程机制必须补位。

第一，状态快照与断点续跑。每完成一个关键步骤，就把中间状态保存下来。如果后续步骤失败，可以回到最近一个检查点重新执行，而不是整个任务重来。这在评测中也要模拟，因为真实业务不允许因为一次网络抖动就丢弃所有进度。

第二，失败重试策略。工具调用失败时，不要立刻让模型做开放式思考，而是先用固定策略重试几次；如果仍然失败，再上报异常。重试可以带退避策略，比如第一次等 1 秒，第二次等 2 秒，第三次等 4 秒。对不同类型的工具，错误码含义不一样，需要单独配置。

第三，关键节点人工审核。在信息输出、资金操作、对外发布等高风险节点，人工确认仍然不可缺少。这不只是安全要求，也是长流程可控性的保障。评测时也应该记录“需要人工介入的次数”作为一个重要指标，次数越少越好，但不能认为零介入才是最优。

如果评测给出模型只有人类 27.3% 的分数，那么这些工程机制就是把你从“不可用”拉到“部分可用”的关键杠杆。即使模型单点能力再提升，没有这些机制，长任务依然不稳。

建议：每次跑完长时程评测，至少留出半小时复盘轨迹。不要只看分数。看模型在哪个环节花了最多时间，哪个错误被重复多次，哪一步需要人工修正。这些数据比 27.3% 这个数字更有参考价值。

5.3 长时程能力的未来还需要什么

最后聊一点更长期的判断。

27.3% 这个数字，既是当前模型的短板，也是评测方法早期阶段的反映。长时程任务评测本身还很年轻，任务设计、评分标准、过程追踪都还没有形成统一范式。现在看到的低分不一定是“模型性能上限”，更可能是“评测维度比以往严格得多”。

未来要真正提升模型的长时程能力，需要两个方向同时推进。一个是模型侧，需要更好的记忆管理、自我评估和错误恢复机制。模型不能只是在推理时更聪明，还需要知道自己做了多久、做对了什么、接下来该干什么。另一个是工程侧，需要更成熟的任务编排和评测基础设施，让长时程任务可以被稳定地构建、运行、监控和复盘。

这两者之间会形成正循环：评测基础设施越好，我们越能看清模型在哪些环节失败；模型能力提升后，又会让更多复杂任务变成可自动化的常规操作。现在投入去做长时程评测，不管是用现成工具还是自己搭一套小流程，都不是浪费时间。

如果你也想从 27.3% 这个数字开始做点什么，不要急着搭一个大型评测平台。先选一个自己最熟悉的任务，把它定义成长时程任务，跑一轮完整轨迹，拆出失败最多的一环，改掉它，再跑一轮。这样持续迭代，你会比模型更快地理解“长时程”这件事的真正难点。而模型的短板，也会在被评测、被记录、被优化的循环里一点点缩短。