内置循环能力对比：两条技术路线的本质差异

一、对比背景：为什么”内置循环”值得单独讨论

在过去一段时间里，围绕代码生成工具的讨论已经从”能不能生成可运行代码”转向”能不能自主完成一个完整目标”。这个转向的核心，是任务循环（task loop）这一机制从外挂脚本走进了产品内核。

所谓”两小时烧掉九亿 token”，本质上是一次极端压力测试：让工具在无人干预的情况下，围绕一个模糊的 /goal 持续迭代，直到它自己判断完成或被迫中止。这类实验暴露出的真正问题不是成本，而是——不同方案对”目标”和”完成”的定义方式完全不同。本文对比的对象，就是两类主流内置循环方案：一类偏重”轻量外挂式循环的内置化”，另一类偏重”原生目标驱动的自主体循环”。为避免指向具体厂商，下文统一称为方案A与方案B。

原始讨论中提到，某平台高管将其能力对标为”某循环范式的内置增强版本”。这句话本身就点明了方案A的定位：把一个原本需要外部脚本编排的循环模式，直接做进产品里。而方案B则走了一条不同的路——它从一开始就把”目标”作为一等公民来设计。

二、对象定义：两类方案分别是什么

方案A：循环内置化路线。
它的思路是：保留”调用—观察—再调用”的经典代理循环，把过去由开发者手写的编排逻辑（如循环控制、状态回传、终止判断）收进产品运行时。开发者给出一个任务，工具自动反复执行，直到满足某个外部或内部条件。它的关键词是循环（loop）。

方案B：目标驱动自主体路线。
它的思路是：先要求开发者把意图表达成一个相对明确的目标，再由系统围绕目标做规划、拆解、执行与自评估。循环只是它内部的实现手段，而不是对外的核心抽象。它的关键词是目标（goal）。

这两者的差别，初看只是”叫法不同”，但在长时间自主运行时会演化成完全不同的行为特征。

三、相同点：它们共享的技术底座

在展开差异之前，需要先承认两者的共同点，否则对比容易失真：

• 都基于多轮工具调用：读写文件、执行命令、检索上下文，本质上都是”模型输出动作—环境返回结果”的循环。
• 都依赖上下文管理：长任务必然面对上下文膨胀，两者都需要压缩、摘要或选择性丢弃历史。
• 都面临终止难题：如何判断”任务已完成”而非”模型自认为完成”，是共有挑战。
• 都需要权限与安全边界：自主执行意味着更高的权限风险，两者都必须设计沙箱、审批或白名单机制。
• 成本模型相似：token 消耗随迭代轮数近似线性甚至超线性增长，长任务成本难以预估。

四、核心差异分析

1. 技术架构：循环在”外”还是目标在”内”

方案A的架构更接近”把编排层下沉“。它保留了显式的循环结构，产品负责驱动这个循环，开发者感知到的是”我给了任务，它在反复跑”。

方案B的架构更接近”把规划层上提“。目标先被解释、拆解成子任务，循环只是执行子任务的手段。开发者感知到的是”我给了目标，它在推进”。

一个直观的伪代码对比：

# 方案A 风格：显式循环
while not done:
    action = model.act(context)
    result = env.execute(action)
    context.append(result)
# 方案B 风格：目标驱动
plan = model.plan(goal)
for subtask in plan:
    execute_with_loop(subtask)
    if not satisfied(subtask):
        replan()

前者终止条件偏”行为层”，后者终止条件偏”目标层”。

2. 功能能力与使用限制

方案A的优势在于通用性强：任何可以用循环描述的任务都能套用，不强制开发者先想清楚目标。缺点是容易陷入”无意义迭代”——循环在跑，但没有逼近目标。

方案B的优势在于方向感强：目标明确时，任务收敛更快。缺点是对目标表达质量敏感，模糊目标会导致规划偏离，且重新规划的成本较高。

3. 接入方式与迁移成本

• 从外挂脚本迁移到方案A：改造量小，因为循环语义基本一致，主要变化是控制权转移。
• 从外挂脚本迁移到方案B：需要重新组织任务描述方式，把”步骤”改写成”目标”，迁移成本更高。
• 两者之间互迁：接口抽象层不同，状态管理和终止逻辑需要重写，属于中等偏高成本。

4. 成本结构

两者都不便宜，但成本曲线不同：

• 方案A的成本更可预测但易失控：每轮开销相对固定，但可能跑很多无效轮次。
• 方案B的成本更前期集中：规划阶段消耗大，但执行阶段收敛快，总成本波动更大。

5. 安全与运维

自主循环越长，风险越大。方案A因为循环显式，容易在循环边界插入审批；方案B因为目标隐含，需要在规划阶段就做权限预判。运维上，方案A的日志更”线性”，方案B的日志更”树状”，后者对可观测性要求更高。

五、对比表格

维度	方案A（循环内置化）	方案B（目标驱动）
核心抽象	循环	目标
终止判断	行为/条件层	目标层
通用性	高	中
收敛效率	依赖条件设计	依赖目标质量
接入改造量	低	中高
成本特征	可预测易失控	前期集中波动大
安全控制点	循环边界	规划阶段
可观测性	线性日志	树状日志

六、典型场景选择

• 任务边界清晰、步骤固定：更适合方案A，循环语义直接。
• 目标明确但路径不确定：更适合方案B，规划能力有价值。
• 需要严格审批与审计：方案A更容易插入检查点。
• 长周期探索型任务：方案B的方向感更占优，但需警惕目标漂移。

七、选型建议

不要问”哪个更好”，而要问”我的任务能不能被清晰表达为目标”。如果答案是能，方案B往往更高效；如果不能，方案A的通用循环更稳妥。团队运维能力有限时，可优先选择控制点更显式、日志更易追踪的方案。

八、迁移与使用注意事项

• 数据与状态：循环状态是否可导出，决定迁移难度。
• 权限模型：目标驱动方案的权限预判更复杂，需提前设计。
• 成本监控：长任务必须设置 token 与轮数上限，避免”两小时九亿”重演。
• 兼容性：接口抽象不同，避免直接复用旧编排脚本。

九、总结

方案A与方案B的本质区别，不在于”有没有循环”，而在于循环之上有没有一个被显式建模的目标。前者把循环做进产品，后者把目标做进架构。理解这一点，才能在选择、迁移和成本控制上做出符合自身任务特征的判断。