Agent 能完成一个任务，但它能持续追一个三个月的目标吗？

最近我一直在思考一个问题：

我们今天构建 AI Agent 的方式，是不是过度围绕"完成一次任务"设计了？

现在大部分 Agent 产品的基本单位都是一次 Run：

你给它一个任务，它理解需求、制定计划、调用工具、执行、验证，然后交付结果。

即使引入了 multi-agent、workflow、subagent，本质上仍然是在优化同一件事：

如何把一次任务做完。

但现实世界里，很多真正重要的工作，并不是一次任务。

它们没有一开始就确定的执行路径，也不会在一次 Run 结束时得到最终答案。

它们需要持续观察外部世界，在不同时间采取行动，等待反馈，再根据结果调整策略。

它们更像一个长期运行的 loop。

Cold email 不是一个任务

比如 cold email。

如果把它写成任务，可能是：

找到 100 个潜在客户，写邮件并发送。

Agent 确实可以一次完成这些动作。

但真正的目标通常不是"发出 100 封邮件"，而是：

找到一套能够稳定产生有效客户对话的 outbound 方法。

这个 Goal 可能持续几周，甚至几个月。

每天只能发送有限数量的邮件。

发完之后，继续运行 Agent 没有意义。它必须等待第二天额度恢复。

有些收件人会在当天回复，有些会在三天后回复；有些标题打开率高，但回复率低；有些文案能获得回复，却吸引了错误类型的客户。

于是，真正的工作过程更像：

观察昨天的数据
→ 检查新回复、退信和额度
→ 判断当前最大的差距
→ 选择今天要测试的人群或文案
→ 发送有限的一批邮件
→ 记录结果
→ 等待新的外部反馈
→ 第二天重新判断

这里，每天是一个小周期。

但整个 Goal 是由许多个日周期组成的。

更重要的是，第二天的行动不能只是重复第一天的 prompt。它应该基于昨天留下的证据，重新决定下一步。

"等待"也是 Goal 的一部分

今天的 Agent 系统通常不太擅长处理等待。

在一个 Run 内，如果 Agent 没有继续执行，它看起来就像停了、失败了，或者被阻塞了。

但在长期 Goal 中，等待经常是正确状态：

• 等待邮件额度恢复
• 等待对方回复
• 等待 CI 完成
• 等待代码评审
• 等待应用商店审核
• 等待一周的数据积累
• 等待用户真正使用新功能
• 等待人工决策

这不是 blocked。

这是：

当前没有值得执行的动作，但 Goal 仍然在继续。

所以我越来越觉得，Heartbeat 不应该简单理解为"定时唤醒 Agent 干活"。

Heartbeat 更应该是：

定时或由事件触发，让 Agent 重新观察世界，并判断现在是否值得行动。

一次成功的 Heartbeat，完全可能只输出：

没有出现新反馈
当前策略无需调整
继续等待
下次检查：明天上午 9 点
如果收到客户回复，则提前唤醒

没有调用工具，没有生成新的任务，也没有消耗大量 token。

但这个 loop 是健康的。

我们最近的发版工作，也是一个真实案例

我们最近一直在优化 Rudder 的发版流程。

表面上看，"发布 v0.6.5"是一个任务。

它有明确的版本号，有发布脚本，也有相对明确的完成条件。

但我们真正想解决的 Goal 不是：

把某一个版本发布出去。

而是：

让每一次发版都能够在一个可预测的时间窗口内完成。

这是两个完全不同的问题。

一次发版偶然很快，并不代表发版系统已经变好了。

我们真正关心的是：

• 从锁定发布代码，到所有公开渠道验证完成，需要多久？
• npm、GitHub Release、Desktop、文档站分别花了多久？
• 时间花在机器执行上，还是花在等待和返工上？
• 为什么有时很快，有时会拖很久？
• 哪个阶段决定了 p90，而不只是平均值？
• 这次修复的瓶颈，在下一次发版中真的消失了吗？

最近我们做了很多具体工作：

• 让发布流程绑定经过验证的准确 source commit
• 尽量复用已经通过的 CI 结果
• 减少重复运行的系统验证
• 把能够快速失败的检查提前
• 避免 canary 和 stable release 相互争抢发布资源
• 缩短 Desktop 构建和验证的等待
• 让发布完成后的下一版本交接更加确定

每一项看起来都像一个独立的 feature 或 fix。

但如果只把它们当作任务，任务合并后就结束了。

只有把它们放回"收敛发版时间"这个长期 Goal，我们才会继续追问：

这个改变有没有让下一次真实发版变得更快、更稳定？

如果没有，那么代码虽然完成了，Goal 却没有前进。

真正的 loop 应该是：

执行一次真实发版
→ 保存每个阶段的时间与失败证据
→ 找到最长尾的瓶颈
→ 提出一个改进假设
→ 完成一个最小改动
→ 在下一次真实发版中验证
→ 保留、调整或回滚
→ 继续寻找新的最大差距

这个 Goal 不属于任何一次发布。

它横跨许多次发布，并通过每一次发布获得新的反馈。

Feature 开发也不是一次直线执行

即使是看起来周期较短的 feature 开发，也存在同样的问题。

我们最近在处理 Messenger 长对话下的滚动性能。

"修复滚动空白"可以是一张 issue。

但真正想得到的结果是：

Messenger 在真实的高压力对话中仍然保持稳定、流畅和可理解。

一次代码修改不能证明这个结果已经实现。

Agent 需要经历多个更小的 loop：

复现问题
→ 提出原因假设
→ 修改最小范围
→ 运行压力测试
→ 在真实界面中观察
→ 检查是否引入新的交互问题
→ 根据结果继续调整

自动化测试通过，只能提供一部分证据。

真实 UI 没有空白，却出现滚动跳动，是新的差距。

单一对话正常，但大量实时更新时再次退化，也是新的差距。

所以对一个 feature 来说，单次 loop 的边界不应该是"写完了多少代码"，而应该是：

是否完成了一次能够产生新证据的验证。

例如：

让 1,000 条消息下的快速滚动不再出现空白，并在真实界面和压力测试中验证。

这是一个可观察、可证伪的小周期。

而"让 Messenger 在真实工作负载下持续流畅"则是一个更长的 Goal。

大 Goal 不是更大的 Task

这也是我目前最重要的判断：

我们不应该通过不断扩大 Task 来表达长期 Goal。

一个持续三个月的 Goal，不应该变成一个持续三个月、永不结束的 Agent session。

长期性不应该依赖一个无限增长的上下文窗口。

它应该存在于持久化的状态、证据和决策里。

每次 Run 结束时，都应该给下一次 Run 留下一个足够小、足够明确的 checkpoint：

当前状态是什么？
这次发生了什么变化？
我们获得了什么证据？
距离目标还差什么？
当前最大的差距是什么？
下一步准备验证什么？
现在应该继续执行，还是等待？
由什么时间或事件再次唤醒？

下一次可以是一个全新的 Agent session。

只要它能读取这些状态，就应该知道为什么这个 Goal 存在、上一次做了什么，以及现在最值得做的下一步是什么。

也许我们需要三层 Loop

我目前倾向于把 Agent 工作拆成三层。

第一层：Run Loop

持续几分钟到几小时。

理解局部目标
→ 提出下一步
→ 执行
→ 观察结果
→ 判断差距
→ 调整或结束

它追求的是一次可验证的进展。

第二层：Heartbeat Loop

持续几天到几周。

读取上一次 checkpoint
→ 检查时间、事件和外界反馈
→ 判断是否需要行动
→ 创建或执行下一项工作
→ 更新状态
→ 设置下一次唤醒条件

它负责跨 Run 保持连续性。

第三层：Goal Loop

持续几周到几个月。

检查核心指标是否收敛
→ 判断当前策略是否仍然有效
→ 找到新的主要瓶颈
→ 调整任务、流程、skill 或资源
→ 从真实结果中学习

它关心的不是"做完了多少任务"，而是外部世界是否真的接近目标状态。

这会带来一组新的产品问题

一旦把 Goal 当成长期 loop，而不是任务分类标签，会出现很多有意思的问题：

Agent 怎么区分"合理等待"和"已经停滞"？

Heartbeat 应该由固定时间触发，还是由事件、指标变化和超时共同触发？

每一次 Run 最少需要保存哪些状态，才能让另一个 Agent 无损接手？

下一步应该由 Goal owner 自己决定，还是由预先定义的 workflow 决定？

如何避免 Agent 为了显得有进展，不断制造无意义的任务？

如何限制长期 Goal 的 token、预算和外部操作？

Goal 的完成应该由 Agent 判断、指标判断，还是必须经过人类 review？

如果局部任务全部完成，但核心指标没有变化，系统应该如何暴露这种"伪进展"？

一个 Goal 是否应该能够修改自己的策略，却不能偷偷修改自己的成功标准？

我觉得这些问题可能比"Agent 能不能再多调用几个工具"更接近下一阶段 Agent 产品需要解决的东西。

Rudder 把 Goal、Task、Chat、Issue、Agent Run、Review 和 Feedback 连接成 Agent 团队的工作 loop。它为人类和 Agent 提供一套共享的工作结构，用来推进工作、运行 Agent、审查产出、控制成本，并保留能让下一次 Run 做得更好的经验。

但我们现在更想进一步回答：

Goal 能不能不只是一个长期的 why，而是成为一个跨越许多 Run、持续观察和缩小差距的工作 loop？

这意味着 Heartbeat 不只是定时执行。

等待必须成为一等状态。

每次 Run 必须留下可以继续的 checkpoint。

Goal 必须能看到真实指标、外部反馈、成本和证据。

系统也必须知道：什么时候应该执行，什么时候应该停下来，什么时候应该换策略，以及什么时候真的可以宣布 Goal achieved。

我还没有觉得这个问题已经有了完整答案。

甚至"Goal controller"是不是正确的抽象，我也不确定。

但我越来越相信：

Agent 真正重要的下一步，可能不是在一次 Run 里变得更强。

而是它能不能在明天、下周，甚至下个月重新回到同一个 Goal，读懂世界发生了什么变化，然后做出一个比今天更好的下一步决定。

如果一个 Agent 能完成任务，却不能长期追踪结果、等待反馈、修正策略，它究竟是在工作，还是只是在执行命令？

很好奇大家会怎么设计这种长期 Goal。