企业官网建设流程全解析

如果你正在做 Agent、自动化工作流或 AI 落地应用，大概已经察觉到一种奇怪的反差：模型在“一问一答”里越来越聪明，可一旦让它独立执行多步骤任务，它就变得不可靠。单看每一步好像都完成了，但整条任务链要么中途走偏，要么反复绕圈，最终交付结果经常要人工返工。这种差距，正是“长时程 AI 任务”评测要暴露的核心问题。

最近一段时间，多个公开评测陆续指向同一个结论：在长时程任务场景下，当前顶尖大模型的整体完成度仅相当于人类基准线的 27.3% 左右。这个数字并不是某个模型单独跑出来的极端值，而是评测范式从“单轮问答准确率”转向“多步骤任务完成度”之后，模型真实能力被重新衡量后的结果。

为什么这个比例值得关注？因为绝大多数真实业务，本质上都是长时程任务。客户投诉处理要经历接单、分类、查记录、给方案、跟进回访；代码修复要经历理解问题、定位文件、写补丁、跑测试、提交 MR；数据分析要经历取数、清洗、建模、出图、写结论。它们都不是一问一答，而是环环相扣的任务链。如果模型只在短任务上表现优异，那它对业务的增量价值就必须打一个问号。

这篇文章我会讲清楚三件事：第一，长时程 AI 任务评测到底在测什么、和传统评测有什么区别；第二，如何搭建一套可落地的轻量级评测框架并跑通最小实现；第三，从 27.3% 这个结果反推，当前模型的短板在哪里，工程上又该如何应对。

1. 这篇文章真正要解决的问题

先说一个真实痛点：很多团队在选型大模型或者验收 Agent 项目时，迷信“单轮准确率”和“榜单分数”。比如模型在 MMLU、GSM8K 这类评测集上考了高分，或者在对话测试里表现很顺，就认为它一定适合深度自动化。但真正进入生产环境后，问题立刻暴露：模型会忘记任务目标、会跳过必要步骤、会在中间一步出错后继续带着错误往下做。

这就是评测指标和业务目标错位导致的“虚高”。

长时程 AI 任务评测想解决的就是这个问题：它不再只问你“模型知不知道答案”，而是问“模型能不能把一件复杂事做完”。它考察的是模型在长时间、多步骤、需要记忆和纠错的任务中的表现，而不是模型在某一个时间点的“知识调用能力”。

什么样的读者应该重点关注这个方向？

• 正在做 Agent、RPA、自动化工作流的开发者；
• 负责模型选型和落地评估的算法工程师；
• 需要设计考核指标来验收 AI 项目的产品经理或团队 leader；
• 以及所有已经意识到“单轮指标不能代表真实效果”的人。

换句话说，如果你只把 AI 当聊天机器人和搜索增强工具，短任务评测还够用；如果你希望 AI 真正参与业务执行，长时程评测就是你绕不开的课题。

2. 什么样的任务才能称为“长时程 AI 任务”

先给一个不太严格但容易理解的定义：凡是需要模型连续执行多个步骤、依赖中间状态、并且单次完成任务往往要持续较长时间或较深推理链的任务，都可以归入长时程 AI 任务的范畴。

它通常有四个典型特征。

第一是“多步骤”。任务不是一步能完成的，至少要经过规划、执行、验证、修正这几个阶段。

第二是“状态依赖”。前一步的输出会成为后一步的输入，中间状态不能丢失。比如“读取订单表 → 过滤异常订单 → 计算退款金额 → 写入退款单”，如果模型在第 2 步丢了几条数据，第 4 步的结果就会全错。

第三是“需要纠错能力”。任务执行过程中一定会出现意外，比如接口返回异常、数据缺失、用户需求变更。模型能不能识别错误、回退到合适位置重新执行，是长时程任务中最有价值的能力项。

第四是“结果可验证”。长时程任务通常需要产出某个业务结果，比如一个文件、一笔订单、一封邮件，或者一个代码提交。这给了评测系统一个客观打分的锚点。

2.1 典型任务画像

注意，长时程并不完全等于“运行时间长”。有的任务虽然耗时短，但依赖链条很深，也需要按长时程任务来评估。真正关键的变量是“状态依赖深度”和“执行步骤数”，时间只是外在表现。

2.2 为什么传统评测在这里失灵

传统评测通常把任务拆成独立的单选题或简答题，模型回答完就立即打分。这种设计有两个隐含假设：每一步之间互不影响，且模型不需要记忆先前状态。但长时程任务恰恰相反，一个错误的中间步骤就像多米诺骨牌，会层层传导到后续步骤。

所以，如果只用传统评测集去衡量长时程能力，结果往往是“骗人”的。这也是很多团队发现“模型在评测集上表现很好，但落地时一塌糊涂”的根本原因。

3. 长时程 AI 任务评测：核心维度与指标设计

要评测长时程任务，第一步是定义“什么叫表现好”。我建议把评测维度拆成六个可量化的方向。

3.1 六个核心维度

1. 任务完成度：最终是否产出了满足要求的交付物。这是最核心的指标，也是“27.3%”这类数字的直接来源。
2. 步骤通过率：任务拆解成若干子步骤后，每一步是否按预期完成。这个指标可以定位模型具体在哪一步开始出错。
3. 状态一致性：模型在任务过程中是否始终维护正确的上下文状态，比如订单集合、文件路径、索引位置。
4. 错误恢复能力：当中间步骤失败时，模型是否能自动发现并修正，还是带着错误继续跑。
5. 效率成本：完成同等质量任务所消耗的 token 数、调用次数和总时长。长时程任务最容易出现问题是“反复试错导致成本失控”。
6. 最终质量：不只是“做没做完”，还要看“做得好不好”。比如代码能不能跑通、报告是否有分析深度。

3.2 综合得分的计算逻辑

综合分不应该是简单平均，更合理的方式是分层计算：

总分 = 任务完成度得分 × 0.4 + 最终质量得分 × 0.3 + 状态一致性得分 × 0.2 + 错误恢复能力得分 × 0.1

其中，任务完成度是“门槛性指标”。如果任务没有完成，最终质量得分必须被压缩，否则模型会通过“输出一堆废话但关键动作缺失”来骗取高分。更严格的评测还会引入“失败惩罚系数”：只要任务失败，总分直接乘以 0.3，甚至归零。

这样做是为了向工程侧传递一个信号：长时程任务里，“做完”比“部分做对”要重要得多。因为在实际业务中，一个只完成 70% 的自动化流程，往往不能直接投入使用，人仍然需要从头 check 一遍，自动化带来的效率增益会被严重削弱。

4. 评测方法：从“单点判分”走向“过程追踪”

长时程任务评测的第二个关键转变，是从只看结果到“过程 + 结果”双重追踪。

4.1 一个完整评测流程的生命周期

一次长时程 AI 任务评测，至少要经过以下环节：

1. 任务定义：把业务目标结构化为评测任务，包含初始输入、可用工具、成功标准。
2. 环境准备：为模型准备一个可执行的沙箱环境，比如临时数据库、文件目录、API 模拟服务。
3. 任务运行：把任务交给模型，记录每一步执行轨迹。
4. 日志采集：保存模型的思考过程、工具调用、状态变化、异常信息。
5. 过程打分：按步骤通过率、状态一致性、错误恢复能力等维度评估轨迹。
6. 结果打分：检查最终交付物是否满足成功标准。
7. 汇总报告：输出综合分、失败原因、瓶颈步骤分析。

这个流程看起来简单，但落地时最难的一点是“如何采集步过程记录”。

4.2 用轨迹日志还原模型行为

如果只是给模型一个最终打分，那和传统评测没区别。长时程评测的真正价值在于轨迹日志（trajectory log）。

一份合格的轨迹日志应该包含：

{ "task_id": "task_004", "status": "failed", "steps": [ { "step": 1, "action": "call_search", "query": "2025年新能源销量数据", "state_before": {}, "state_after": {"data_source": "web"}, "success": true }, { "step": 2, "action": "parse_table", "state_before": {"data_source": "web"}, "state_after": {"order_count": 1024}, "success": false, "error": "字段解析失败" } ], "final_output": null, "total_cost": 3821 }

通过这种日志，评测系统可以极其精确地定位：模型在哪一步第一次偏离了正确路径、偏离的原因是工具调用错误还是状态丢失、后续有没有自我修正。这比单纯看总分有用得多。

4.3 过程打分和结果打分怎么配合

目前比较成熟的做法是“规则打分 + 模型打分”结合。

规则打分负责硬性指标：步骤是否执行、工具调用是否合法、状态是否符合预期。这些指标是客观的，可以直接写代码判断。

模型打分负责软性指标：最终交付物的质量、回复的专业程度、方案的合理性。这部分通常用强模型作为裁判，但要注意法官偏差问题，最好用多个模型交叉打分并计算一致性。

为了让硬性指标和软性指标不互相干扰，我建议把过程分和结果分分开汇报，而不是直接合并成一个数字。比如报告里同时给出“完成度：30% / 步骤通过率：45% / 质量分：3.2/5”，这样团队能根据业务优先级做取舍。

5. 环境准备与评测框架搭建

下面进入实操部分。我们用一个最小可运行的 Python 评测框架，演示如何搭建长时程 AI 任务评测。这里不依赖任何第三方评测平台，完全用通用脚本实现。

5.1 环境要求

建议环境如下，版本请以当前主流稳定版为准：

• Python 3.10 或以上
• pip 或 uv
• 一个可调用的模型 API，本文用 OpenAI 兼容接口简化演示
• 可选：pandas 用于分析结果

创建虚拟环境并安装依赖：

python -m venv venv source venv/bin/activate pip install openai pandas pyyaml

如果使用国产模型或私有化部署模型，只需要把 client 的 base_url 和 api_key 换成自己的地址即可。

5.2 评测数据集设计

评测数据集是长时程评测的灵魂。我提供一个轻量 JSON 结构的任务定义示例：

{ "task_id": "data_report_001", "name": "生成月度销售报告", "description": "从销售数据库中读取数据，按区域聚合，计算同比增长，生成 Markdown 报告", "initial_input": { "database": "sales.db", "month": "2025-01", "output_path": "report.md" }, "available_tools": ["read_db", "aggregate", "calculate_ratio", "write_file"], "success_criteria": [ "报告文件存在", "包含三个区域的数据", "包含同比增长率", "数字与数据库原始值一致" ], "expected_steps": ["connect_db", "query_sales", "aggregate_by_region", "calculate_yoy", "write_report"], "max_steps": 10 }

这个数据集的作用有两个。一是给模型提供任务初始信息；二是给评测脚本提供“裁判标准”。其中expected_steps是可选的参考路径，它不要求模型严格按这个顺序执行，但可以用它做步骤重叠度分析。

5.3 评测框架的核心模块

一个最小评测框架至少包含四个模块：

• Executor：负责调用模型、维护状态、记录轨迹。
• Judge：负责判断步骤是否成功、结果是否满足标准。
• Logger：负责保存轨迹日志。
• Analyzer：负责汇总指标、生成报告。

我们下面用 Python 实现一个简化版。

6. 完整示例：一个轻量级长时程任务评测实现

这一节我们写一个完整的评测脚本。核心思路是：给模型一组工具，让它去完成一个模拟的“数据报告生成”任务，然后我们记录每一步行为，并给出过程指标。

6.1 定义基础数据结构

# 文件路径：eval_framework/models.py from dataclasses import dataclass, field from typing import Any, Callable, Optional @dataclass class ToolResult: status: str # "success" | "error" | "timeout" data: Any = None error: Optional[str] = None @dataclass class StepRecord: step_index: int action: str input_snapshot: dict output_snapshot: dict success: bool cost_tokens: int = 0 @dataclass class TaskResult: task_id: str status: str # "completed" | "failed" | "aborted" steps: list = field(default_factory=list) final_output: Any = None total_tokens: int = 0 error_summary: list = field(default_factory=list)

这段代码定义了评测框架的基本数据模型。StepRecord记录每一步的动作、输入输出快照和成功状态；TaskResult保存整个任务的最终结果。有了这个结构，评测脚本就可以非常方便地展开成表格或 JSON。

6.2 实现评测执行器

接下来是评测执行器。为了让示例简短，我们把“模型调用”替换成一个模拟 Agent 函数，实际使用时替换为大模型 API 即可。

# 文件路径：eval_framework/evaluator.py import json import time from typing import Any, Callable, Optional from models import TaskResult, StepRecord, ToolResult class LongTaskEvaluator: def __init__(self, max_steps: int = 10, token_limit: int = 8000): self.max_steps = max_steps self.token_limit = token_limit self.logs = [] def run(self, task: dict, agent_fn: Callable) -> TaskResult: task_id = task["task_id"] state = task.get("initial_input", {}) result = TaskResult(task_id=task_id, status="failed") total_tokens = 0 for step_idx in range(1, self.max_steps + 1): # 调用 Agent，获得下一步动作 action, current_tokens = self._call_agent(agent_fn, task, state) total_tokens += current_tokens # 执行动作（真实项目中会分发到具体工具） tool_result = self._dispatch(action, task, state) record = StepRecord( step_index=step_idx, action=action.get("name", "unknown_action"), input_snapshot=dict(state), output_snapshot=tool_result.data or {}, success=(tool_result.status == "success"), cost_tokens=current_tokens, ) result.steps.append(record) if tool_result.status == "error": result.error_summary.append({ "step": step_idx, "action": record.action, "error": tool_result.error }) state["last_error"] = tool_result.error else: state.update(tool_result.data or {}) if action.get("type") == "finish": result.status = "completed" result.final_output = tool_result.data break result.total_tokens = total_tokens # 判断是否超过 token 上限 if result.status != "completed" and total_tokens > self.token_limit: result.status = "aborted" result.error_summary.append({"step": -1, "action": "token_limit", "error": "token 超限"}) self.logs.append(result) return result def _call_agent(self, agent_fn, task, state): # 真实项目中应改为 model_api.chat(prompt, tools) return agent_fn(task, state) def _dispatch(self, action, task, state): # 简化分发器，真实项目需要工具注册表 tool_name = action.get("name", "") if tool_name == "query_data": mock_data = { "total_sales": 1200000, "regions": ["华东", "华南", "华北"], "report_done": True, } return ToolResult(status="success", data=mock_data) if tool_name == "write_report": return ToolResult(status="success", data={"output_path": state.get("output_path")}) if tool_name == "finish": return ToolResult(status="success", data=state.get("output_path")) return ToolResult(status="error", error=f"unknown tool: {tool_name}")

这个执行器虽然简化，但保留了长时程评测的关键逻辑：循环运行、状态更新、错误记录、token 统计、任务终止条件。真实项目里，_dispatch会替换为真正的工具调用，_call_agent会变成模型 API 请求。

6.3 实现评分器

执行完成后，需要按照我们前面定义的维度打分。

# 文件路径：eval_framework/judge.py from models import TaskResult class Scorer: def __init__(self, success_criteria: list): self.success_criteria = success_criteria def score(self, task_result: TaskResult) -> dict: if task_result.status != "completed": return { "task_id": task_result.task_id, "completion_score": 0.0, "step_pass_rate": 0.0, "state_consistency": 0.0, "error_recovery": 0.0, "final_quality": 0.0, "total_score": 0.0, } steps = task_result.steps passed = [s for s in steps if s.success] step_pass_rate = len(passed) / len(steps) # 完成度：只要最终成功，视为 1.0；如果后续接入结果校验，可以细化 completion_score = 1.0 # 误差恢复：有错误但后面继续完成为加分项；完全无错误也可以给满 error_count = len(task_result.error_summary) error_recovery = 1.0 if error_count == 0 else (1.0 if task_result.status == "completed" else 0.3) # 最终质量：这里简化为判空，真实项目需要接入 quality judge final_quality = 1.0 if task_result.final_output else 0.0 total_score = ( completion_score * 0.4 + final_quality * 0.3 + step_pass_rate * 0.2 + error_recovery * 0.1 ) return { "task_id": task_result.task_id, "completion_score": completion_score, "step_pass_rate": round(step_pass_rate, 4), "state_consistency": round(step_pass_rate, 4), "error_recovery": error_recovery, "final_quality": final_quality, "total_score": round(total_score, 4), }

这里有一个设计细节值得注意：错误恢复得分的判断。当一个任务最终成功时，即使中间出现错误，错误恢复也按 1.0 算，这其实是在奖励 Agent 的自我修正能力。不过这样也会带来一个新问题：如果模型每步都出错但每次都能改对，最终也能拿到高分。所以更严格的评测还应该加一个“错误代价惩罚”，例如error_recovery = 1.0 if 完成且 error_count <= 2 else 0.7。具体阈值要根据业务容忍度调节。

6.4 模拟 Agent 与运行

我们写一个模拟 Agent 来演示整个流程。它会在第 3 步故意触发一个错误，然后恢复，用来展示记录机制。

# 文件路径：eval_framework/run_demo.py from evaluator import LongTaskEvaluator from judge import Scorer def mock_agent(task, state): # 模拟一个 Agent 的决策逻辑 step_count = state.get("_step", 0) + 1 state["_step"] = step_count if "last_error" in state: delete state["last_error"] action = {"name": "query_data", "type": "tool"} return action, 120 if step_count <= 3: action = {"name": "query_data", "type": "tool"} if step_count == 3: # 模拟一次错误 action = {"name": "error_action", "type": "tool"} return action, 100 return {"name": "finish", "type": "finish"}, 90 if __name__ == "__main__": task = { "task_id": "data_report_001", "initial_input": {"output_path": "/tmp/report.md"}, } evaluator = LongTaskEvaluator(max_steps=8) scorer = Scorer(success_criteria=[]) result = evaluator.run(task, mock_agent) score = scorer.score(result) print(json.dumps(score, ensure_ascii=False, indent=2))

注意，上面的代码片段里我写了delete state["last_error"]，这个写法在 Python 中是不合法的，必须写成：

if "last_error" in state: state.pop("last_error", None)

在真实开发中，这也提醒我们：评测脚本本身必须经过充分测试，不能因为评测代码 bug 导致模型表现被误判。评测工具质量不过关，结果比不评测更有害。

修正后的模拟 Agent 如下：

def mock_agent(task, state): step_count = state.get("_step", 0) + 1 state["_step"] = step_count if "last_error" in state: state.pop("last_error", None) return {"name": "query_data", "type": "tool"}, 120 if step_count <= 3: if step_count == 3: return {"name": "error_action", "type": "tool"}, 100 return {"name": "query_data", "type": "tool"}, 100 return {"name": "finish", "type": "finish"}, 90

6.5 运行结果与验证

运行 demo：

python run_demo.py

预期输出：

{ "task_id": "data_report_001", "completion_score": 1.0, "step_pass_rate": 0.8571, "state_consistency": 0.8571, "error_recovery": 1.0, "final_quality": 1.0, "total_score": 0.9 }

如何判断评测是否成功？重点不是看这个模拟任务的分数高低，而是看：

1. 轨迹日志是否完整记录了每一步动作；
2. 错误有没有被记录到error_summary；
3. 评分是否符合预期逻辑。

如果运行报错，先检查 Python 版本、模块导入路径，以及是否有未安装的依赖。这个最小框架已经跑通了“任务定义 → 执行 → 打分”的完整链路，实际接入模型时，只需要替换mock_agent为真实模型调用即可。

7. 从 27.3% 反推模型的长时程短板

如果 27.3% 这类评测结果可信，那我们不应该只把它当成“模型不行”的结论，更应该追问：模型究竟是在哪个环节丢的分？

从目前大量长时程评测和 Agent 案例来看，丢分通常集中在以下五个方面。

7.1 任务规划漂移

模型在开始时能给出合理的任务计划，但执行到中后段会逐渐忘记最初的约束条件。比如任务要求“只统计华东区域数据”，模型可能在中途把其他区域的数据也加进来。原因在于长上下文下，模型对初始指令的注意力权重被后续大量中间信息稀释了。

7.2 状态记忆丢失

长时程任务天然要求模型维护运行状态，但如果 Agent 架构把状态放在对话上下文里，很容易被后续内容“挤出去”。典型表现是：模型重复查询已经查过的数据，或者基于过期状态做决策。

7.3 错误累积

单步错误率相乘后，整个任务的成功率呈指数下降。假设每步正确率是 97%，一个 20 步任务的整体正确率只有约 54%。如果是 30 步任务，整体正确率更会降到 40% 左右。这提醒我们：长时程任务不能只靠模型本身能力，还要靠架构补偿。

7.4 工具调用冗余

很多模型在长时程任务中会出现“无效工具调用”，比如反复搜索同一个关键词、重复写入同一份文件。这不仅浪费 token，还会把上下文状态搅乱。评测中的效率分，本质上就是用来压制这类无效行为的。

7.5 缺乏主动结束能力

一些模型在任务已经完成时不会主动停止，而是继续“加戏”。这在评测中会导致完成度不错但质量分被拉低；在生产环境中则会产生错误副作用，比如重复发送邮件或重复提交订单。

知道了这些短板，工程侧就能有针对性做优化，而不是盲目追求一个“更贵的模型”。

8. 真实项目落地：评测只是第一步

评测的价值在于指导优化，而不是为了得到一个分数。在真实项目中，我建议从三个层面使用长时程评测。

8.1 用评测结果做模型选型

采购模型或选择 API 时，不要只看常规榜单，应该有自己业务场景的长时程评测集。这套评测集不需要很大，20 到 50 个代表性任务就够了，但必须覆盖三类场景：高频操作、高危操作、长尾异常。高频操作看效率，高危操作看可靠性，长尾异常看错误恢复。

8.2 用评测定位架构缺陷

如果完成度低，先区分是模型问题还是架构问题。方法很简单：把同一个模型接入两种不同的 Agent 框架，对比完成度。如果完成度提升明显，说明问题出在架构的提示词、记忆管理或工具编排上；如果没提升，那可能是模型基础能力不足，需要换模型或做微调。

8.3 用评测建立回归门禁

持续迭代 Agent 时，长时程评测要像单元测试一样跑回归。每次修改提示词、工具定义或模型版本，都需要在同一套评测集上重新跑一遍。这里推荐引入“基线对比”机制：把当前线上的 Agent 版本作为 baseline，新版本至少要保证核心指标的完成度不低于基线，才允许上线。

9. 常见问题与排查思路

这里整理一份长时程 AI 任务评测中常见的踩坑清单。

另外还有一个容易被忽略的问题：评测集本身会过时。当你把工具 schema、数据库字段或者业务流程改了，旧的评测集可能不再适合当前系统。所以每隔一个迭代周期，需要人工审核一遍评测集，删除无效任务、补充新场景。

10. 最佳实践与工程建议

基于前面的原理和示例，我整理了一份相对完整的最佳实践清单。

10.1 评测集建设

建议从真实业务日志中抽取任务，而不是靠算法同事凭空编造。具体做法是：先收集 30 天的真实用户操作日志，按任务目标聚类，再人工整理成标准化评测任务。每个任务必须包含“明确的目标”“可操作的初始状态”“可验证的成功标准”。

10.2 过程日志与可观测性

长时程任务评测一定要和可观测性绑定。每个 Agent 运行实例都必须输出：

• 步骤序号；
• 动作类型；
• 输入状态摘要；
• 输出状态摘要；
• 耗时和 token 消耗；
• 异常堆栈或错误信息。

有了这份日志，评测失败时才能快速定位到具体环节。否则，你只知道“模型失败了”，但完全不知道它为什么失败。

10.3 指标组合

不要只用一个总分，建议至少同时关注四个数：

• 完成度：任务有没有在限定步骤内做完。
• 核心步骤通过率：关键路径上的步骤是否正确。
• token 效率：每完成一项任务平均消耗多少 token。
• 人工介入率：有多少任务需要人工重跑或修复。

人工介入率是生产环境最重要的指标，因为它直接决定自动化系统是否划算。

10.4 安全与最小权限

长时程 Agent 评测往往需要在模拟环境中执行工具调用，这涉及权限问题。一定要遵循最小权限原则：评测环境使用独立的测试数据库、测试支付账号、测试邮箱，不能接入生产环境。即使做真实环境评测，也要先在小流量、可回滚的范围内进行。

10.5 版本管理与回归

把评测集、评测脚本、模型版本、提示词版本全部纳入 Git 管理。任何一个可复现的评测结果，都需要同时记录四份版本信息。当线上 Agent 行为异常时，你可以通过版本记录快速定位到是哪一次改动引起的。

11. 总结

长时程 AI 任务评测的核心，是把注意力从“模型会不会答”转移到“模型会不会做”。27.3% 这个数字是否精确并不重要，重要的是它揭示了当前模型的真实软肋：在复杂任务链上，模型距离人类水平还有很大距离。

对开发者来说，与其焦虑模型能力不够，不如尽早把长时程评测接入自己的项目流程。一是积累属于自己业务的评测集，二是建立“执行轨迹 + 多层评分”的评测框架，三是把评测结果用于模型选型和架构优化。这套体系做起来并不复杂，今天的示例代码已经给出了最小闭环，你完全可以在这个基础上扩展成适合自己项目的评测平台。

下一步建议从三个方向深入：一是研究 Agent 的记忆管理机制，比如引入显式状态存储来缓解“状态记忆丢失”；二是改进评测集的质量，让任务更贴近真实业务；三是关注行业里公开的长时程评测方法和工具集，比如 swe-bench 这类代码场景基准，参考它们的任务拆分和评分设计思路。

长时程评测不是一次性的动作，而是一种工程习惯。养成这个习惯，你评估任何模型、任何 Agent 框架时，都会比只看榜单的人更接近真实答案。