长程Agent的定义是什么？什么情况下算是长程?有没有量化的比如工具调用次数，上下文窗口，压缩比例，子Agent等具体指标?

先举个例子：让 Agent 完成一次大型代码库迁移，它要理解旧实现、制定方案、修改多个模块、跑测试，再根据失败结果返工。后面的决策依赖前面做过什么，期间还得持续记住约束和未解决问题——这是典型的长程任务。 反过来，让 Agent 连续查 1000 个互不相关的天气，即使调用工具很多、跑了一整天，也不太能说明它有长程能力。 核心结论：长程主要描述任务的跨度及跨步骤依赖，不是某种固定架构。没有通用的“超过 100 次工具调用就算长程”这类硬门槛。 一、定义要区分两种口径 工程语境里的 long-horizon Agent，通常指能围绕同一个目标，在较长的、相互依赖的行动序列中持续推进，维持任务状态，并根据反馈调整行动的 Agent。 Anthropic 的上下文工程文章采用了更具体的描述：行动序列产生的 token 超过上下文窗口，Agent 仍要保持连贯性、上下文和目标导向；举例是持续几十分钟到数小时的代码迁移、研究任务。 但这是该文章的工程讨论口径，不意味着“没触发压缩就不算长程”。 另外，long-running 强调运行时间长，long-horizon 更强调完成目标需要跨越较长的决策链。等一个训练任务跑十小时，不等于自主决策了十小时。 二、你提到的指标，各自能说明什么？ 工具调用次数：能描述交互规模，不能单独定义长程。 100 次独立搜索，与根据测试反馈连续定位、修复问题的 100 次调用，依赖深度完全不同。而且一个工具可能封装很多操作，工具粒度不同，次数就不可直接比较。最好同时记录决策轮数、工具调用数、重试次数。 上下文窗口：是资源上限，不是任务跨度。 支持百万 token，不等于能持续完成复杂任务；窗口较小但会维护外部状态的 Agent，也可能完成长程任务。应区分窗口容量、实际峰值占用，以及整个轨迹累计产生的数据量，别把重复输入的历史 token 都算成新增任务信息。 压缩次数和压缩比例：是上下文管理指标，不是能力证明。 把 100k token 压到 10k，可以写成“保留比例 10%”或“压缩倍数 10 倍”，避免“压缩率”口径歧义。 真正重要的是压缩后是否遗忘约束、重复已完成工作、丢失失败经验，以及最终成功率是否下降。压得多不代表做得好，也可能只是工具输出太冗余。 子 Agent 数量：是架构指标，不是长程门槛。 单 Agent 可以做长程任务；20 个子 Agent 同时完成独立小任务，也不自动意味着长程。应看主线任务的依赖链、交接信息是否完整，以及整合结果是否成功，而不是数 Agent。 实际运行时长：有参考价值，但要拆分。 至少区分总耗时、模型与工具执行时间、外部等待时间，并记录人工介入。否则“自主运行八小时”可能主要是在等接口，或者期间用户一直帮它纠错。 三、有没有比较正式的量化指标？ 有，METR 的 task-completion time horizon 是一个明确的评测口径。 它衡量的是：在某个成功率水平下，Agent 能完成的任务，对应人类专家需要多长时间。 例如，假设一个系统的“80% time horizon 为 2 小时”，意思是在其评测任务分布和拟合模型下，对应人类专家约两小时工作量的任务，系统预测成功率为 80%。 不是说 Agent 自己能连续运行两小时，也不是说所有两小时任务它都有 80% 把握。 METR 会用人类完成时间作为横轴、Agent 成功概率作为纵轴拟合曲线，报告 50% 或 80% 对应的时间跨度。其任务主要来自软件工程、机器学习和网络安全，不能直接推广到所有工作。 还有一个关键限制：任务得是有内在联系的工作单元。METR 明确指出，1000 道独立的一小时数学题，不应算成一个千小时任务。 四、实际怎么判断“算不算长程”？ 我会重点看三个问题，这是工程判断方式，不是行业统一标准： 它是否为了同一个可验收目标，经历多阶段、相互依赖的决策，而不是批量重复独立任务？ 它是否必须保留早期约束、决策和失败经验，才能做好后面的工作？ 它是否能在中途失败、上下文切换或计划变化后，继续推进并最终通过验收，而不是靠人逐步指挥？ 量化报告则应以“任务跨度 × 成功率”为主，再补充决策轮数、工具调用量、token 消耗、压缩情况、耗时和人工介入次数。 一句话概括：长程的重点不是“跑得久、调得多”，而是“在较长的依赖链上，持续正确地推进同一个目标”。调用次数、压缩和子 Agent 都是辅助观测，最终要落到完成能力与可靠性。 参考： METR 的量化定义与限制 https://metr.org/time-horizons/ Anthropic 的长程任务与上下文工程讨论 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents