如果让你手下一个人去负责一条生产链路他每天都在汇报“我做了 A、做了 B、做了 C”但一周后核心业务指标没有任何变化你会怎么评价他当前不少 AI Agent 项目恰恰就处在这样一个状态规划模块能生成看起来合理的步骤能调用工具日志里每一步都有输出但整体任务就是卡着不动。于是大家把问题归结为“模型规划能力差”。可这个“差”到底差在哪里很多团队的答案是模型一直在选那些容易的、眼前收益高的实验却迟迟不去解决最关键的那个难点。这篇文章想聊一个偏前沿的规划思路——Capability-Gated Planning能力门控规划以及它背后的两个核心概念Cost-to-Goal Discovery到达目标的成本发现和 Myopic Experiment Selection近视实验选择。我的核心判断是限制 Agent 的往往不是“下一步该做什么”而是“它离目标到底还有多远”以及“哪些差距来自当前能力边界”。如果你正在做 LLM Agent、自动化决策链路或者任何一个需要自主规划的模块这篇文章能帮你重新审视规划器的设计方式。1. 这篇文章真正要解决的问题先描述一个非常常见的开发场景。你写了一个 Agent它在任务开始时先拆解目标然后逐项执行。第一天它去搜索资料第二天它生成了一段代码第三天它把代码跑通第四天它发现跑出的结果和预期不符。之后它开始频繁更换策略换提示词、换参数、换调用方式但一直停在“验证失败”这个环节。你去看日志发现它确实在做事情问题在于它做的实验都太“轻”了——搜索、改写、调用低风险 API这些实验单步成功率很高反馈也很好但累积下来并没有推动任务核心进展。这个现象就是 Myopic Experiment Selection翻译成“近视实验选择”很贴切。规划器在选择下一步实验时只关注“当前这个动作看起来能不能成功”而不关注“这个动作会不会显著缩短我到达目标的距离”。这篇文章要解决的问题不是“怎么生成步骤”而是“怎么让规划器知道自己和目标之间到底隔了多少成本”。传统规划思路是给定一个目标然后展开动作序列能力门控规划的思路正好反过来先评估当前能力距离目标有多远再决定要不要继续规划、选择什么类型的实验。它表面上是一种规划方法本质上是一种关于“代价感知”的训练与决策框架。为什么值得关注因为 LangChain 之类的 Agent 框架已经解决了很多“组织工具调用”的问题但进入复杂长任务后真正的瓶颈转移到了“如何选择行动序列”这件事上。而选择行动序列的关键不是你拥有多少工具而是你是否拥有一套能估计“到目标还需要多少代价”的机制。能力门控规划就是针对这个缺口提出的一种系统化方案。2. 核心概念拆解门控、代价与近视实验选择三个术语放在一起容易让人头晕但它们各自的角色其实很清楚。2.1 Capacity-Gated Planning先问“我能不能”再问“我怎么做”能力门控规划英文对应 Capability-Gated Planning核心思想是在规划动作之前先做一个关于“能力边界”的判断。普通 Agent 的行为链是目标 - 拆解步骤 - 执行步骤能力门控规划的行为链多了一层目标 - 判断“当前能力是否跨过了门槛” - 如果没跨过先做能力提升/外部求助 - 如果跨过再进入规划与执行这里的“能力”可以是一个模型的多项技能集合比如信息检索、代码生成、数学推理、环境交互也可以是一个团队的技能集合。门控的作用是过滤掉那些“当前能力明显达不到”的任务避免规划器在能力不匹配的路径上做无谓尝试。这个设计看起来简单但实际价值在于它把“能不能做”和“怎么做”拆成了两个独立问题。我们在 Agent 开发中经常看到模型被要求做一件它本身不具备能力的事它依然会硬着头皮生成一个规划然后在执行中反复失败。能力门控就是专门挡住这种情况。2.2 Cost-to-Goal Discovery发现的是“距离”不是“奖励”Cost-to-Goal Discovery直译是“到目标的成本发现”。这个词来自强化学习里的 cost-to-go 函数也有地方叫 value function。它的定义是从当前状态出发完成到目标状态所需的预期累计代价。注意这里的重点是“预期累计代价”不是“下一步的即时收益”。举个例子。你现在要开发一个推荐系统当前状态是“有历史数据但没有特征工程”目标是“上线一个离线评估 AUC 超过 0.75 的模型”。下一步实验可以是“补 10 个用户画像特征”也可以是“尝试 XGBoost 超参调优”。从及时反馈看后者很可能更快看到指标变化但从到达目标的长期代价看前者可能更关键。Cost-to-Goal Discovery 要计算的是这两种选择分别让“到目标的剩余代价”降低了多少。在经典的图搜索算法里这对应 A* 算法中的启发式代价也对应 Dijkstra 算法里的全局距离更新。Cost-to-Goal 不是告诉你“这个实验会不会成功”而是告诉你“这个实验是否让你离终点更近”。2.3 Myopic Experiment Selection只看眼前一步的选择策略近视实验选择是能力门控规划要修正的对象。“Myopic”在经济学里是“短视”的意思。一个近视的规划器在选择实验时通常只采用两种判断标准之一这个实验的成功概率高不高这个实验的即时回报大不大这两个标准有一个共同缺陷没有把“当前实验执行完之后后面还有多少路要走”纳入计算。于是它倾向于选择“看起来容易成功”的步骤而不是“对全局最必要”的步骤。我在接入很多 Agent 框架时观察到一个很典型的现象模型非常喜欢选择“读取文件”“查询数据库”“调用搜索 API”这类低风险操作因为单步成功率高而像“修改核心配置”“构造复杂 JSON 请求”“根据日志判断根因”这类高风险但高价值动作会被反复拖延甚至忽略。这就是近视实验选择在真实项目中的表现。特征Capability-Gated PlanningCost-to-Goal DiscoveryMyopic Experiment Selection回答的问题当前能力是否匹配任务当前状态离目标还有多远下一个实验该选哪个决策尺度任务级全局路径级单步级对失败的容忍高先过滤再执行中允许走弯路但会修正低尽量选易成功的动作失败典型表现任务被误判为不可达代价估计不准导致绕路完成大量低价值子任务适合场景能力边界明显的任务长链路、多阶段任务单步收益明确的短期任务3. 为什么“发现成本”比“选下一步实验”更本质很多做 Agent 的同学会困惑规划本身不就是“选下一步实验”吗为什么要把“发现成本”单独拿出来说因为“选下一步”和“知道还有多远”是两个层次的决策。一个只负责选下一步实验的规划器本质上是贪心算法。它每一步选一个“当前看起来最优”的动作但没有任何机制保证这些局部最优叠加起来是全局最优。在数学上贪心算法只有在满足特定条件时才能得到最优解在真实 Agent 任务里几乎不存在这些条件。而能力门控规划真正关心的是先建立一个“代价地图”。如果你知道从当前状态到目标的最低预期代价是 7 个单位那么任何代价超过 7 的动作都会被淘汰如果你只有“当前动作成功率”而没有“剩余成本”你就没有判断依据。我用一个生活中的类比来说明。假设你要从一座荒岛出发走到岛的另一端。你有两个选择一是花 10 分钟把路边容易捡到的野果都采下来二是花 30 分钟把断桥修好。采野果的即时收益很高你马上有食物了但修桥才能让你继续前进。一个只做“下一步实验选择”的规划器会一直采野果因为它每步都在获得即时奖励。而一个先做“成本发现”的规划器会知道修完桥后剩余路程的代价是 20 分钟不修桥无论采多少野果剩余路程都是无穷大。这个类比可以原封不动映射到 Agent 任务里。Agent 在规划时需要的不是“哪个工具调用起来更顺手”而是“哪条路径会让到达目标的剩余代价显著下降”。Cost-to-Goal Discovery 还提供了一个非常实用的视角把“不确定性”计入代价。从状态 A 到目标如果两条路径的总代价相同但一条路径的方差更大那么稳健的做法是选方差小的路径。这一点在 LLM Agent 里特别重要因为大模型生成动作的随机性很高同样的路径可能这次成功、下次失败。把不确定性纳入代价估计门控规划的质量会明显提升。4. 能力门控规划的核心流程拆解下面把能力门控规划拆成四个阶段。这样做不是为了让你立刻去实现一个完整框架而是为了帮助你理解“门控”这个词到底是在哪一层发生的。4.1 阶段一构建能力清单第一阶段是建立“能力清单”。这里的能力包括工具调用能力、模型推理能力、外部知识获取能力甚至包括“在失败 n 次后是否切换策略”的元能力。在这个阶段需要回答的问题不是“我应该怎么解决这个任务”而是“我目前拥有哪些解决这个任务的资源”。实际操作中你应该为每一项能力标注三个属性能力名称比如“代码执行器”适用条件比如“需要 Python 3.8”置信度比如“在这个领域内成功率约 80%”这里容易犯的错误是只写“有什么工具”不写“工具能保证什么”。能力清单如果没有置信度信息后面的门控判断就是空谈。4.2 阶段二估计 Cost-to-Goal第二阶段是关键。你需要一个代价估计器它输入当前状态和目标输出一个标量预期剩余代价。这个估计器可以从两个方向构建。第一种是人类专家规则把任务拆成若干阶段给每个阶段打一个预期耗时或失败风险然后求和。这种方法在小规模任务里可用但扩展性差。第二种是从历史轨迹中学习记下大量“状态-动作-结果-成本”四元组训练一个小型回归模型来预测“从当前状态到目标还需要多少步”或“还需要付出多少代价”。这是更工程化的做法也是后续章节里我会给出伪代码的部分。代价估计器输出的含义要定义清楚。它可以是“预期步数”也可以是“预期试错次数”还可以是“预期风险损失”。我建议团队在初期把代价定义成“预期剩余步数”因为它最容易理解、也最容易验证。4.3 阶段三能力门控决策拿到能力清单和代价估计后就到了“门控”所在的阶段。门控逻辑可以写得很简单if 预计剩余代价 可接受阈值: 进入详细规划与执行 else: 不进入当前规划触发能力提升或外部求助但这个简单逻辑背后有三个要点。第一阈值不是固定的。它随着任务价值、可用算力、用户耐心动态变化。任务价值高时阈值可以放宽算力紧张时阈值应当收紧。第二门控要区分“能力不足”和“代价过高”。如果模型判断自己“完全不会做”应该走“能力提升”分支如果模型判断“可以做到但代价很大”应该走“资源申请”分支。两种情况的处理方式完全不同。第三门控不能让执行变得过于保守。如果任何高代价任务都被门控拦截Agent 就退化成一个只做简单任务的工具这违背了加入规划模块的初衷。4.4 阶段四执行与代价校准执行阶段不是终点。执行过程中会产生真实的代价反馈这些反馈要用来更新代价估计器。这一步非常重要。代价估计很少能一次算准它需要不断校准。校准的机制可以参照强化学习里的 Temporal Difference时间差分思想新的代价估计 当前估计 学习率 * (实际支付代价 未来代价估计 - 当前估计)用大白话说如果你预测从 A 到目标要 3 步实际执行后发现从 A 到 B 用了 1 步而从 B 到目标又需要 4 步那么你会把 A 的代价估计从 3 修正成更接近 145 的值。这个更新公式就是 Cost-to-Goal Discovery 从理论走向工程的关键。5. 完整示例一个最小能力门控规划实现本章用一个很小的 Python 示例演示能力门控规划的主干逻辑。它不会依赖任何特定 Agent 框架你也可以把它改造成自己的规划器原型。5.1 定义核心数据结构先定义状态、能力和代价估计器的数据结构。# 文件路径ccgp/models.py from dataclasses import dataclass, field from typing import Dict, List, Callable, Optional dataclass class Capability: Agent 拥有的一项能力 name: str apply_condition: Callable[[AgentState], bool] success_rate: float 0.5 cost: float 1.0 dataclass class AgentState: 当前 Agent 状态可以简单理解为一组特征字典 features: Dict[str, float] goal_features: Dict[str, float] field(default_factorydict) def distance_to_goal(self) - float: 简化版距离计算当前特征与目标特征的差异 if not self.goal_features: return 999.0 diff 0.0 for key, target_value in self.goal_features.items(): cur_value self.features.get(key, 0.0) diff abs(cur_value - target_value) return diff dataclass class CostEstimator: 从状态特征预测到达目标剩余代价的估计器 base_cost: float 5.0 penalty_coef: float 0.2 def predict(self, state: AgentState) - float: # 先用距离作为代理指标真实项目中可以换成训练好的回归模型 return self.base_cost self.penalty_coef * state.distance_to_goal() def update(self, current_state: AgentState, actual_cost: float, next_state: AgentState, learning_rate: float 0.1) - None: 使用 TD 思想校准代价估计 predicted_cost self.predict(current_state) future_cost self.predict(next_state) td_target actual_cost future_cost # 调整 base_cost等于把误差反向传播到基础常数上 error td_target - predicted_cost self.base_cost max(0.1, self.base_cost learning_rate * error)这段代码里distance_to_goal()是最朴素的代价度量方式。真正的项目里它可能是一个通过历史轨迹训练出来的回归模型但数据结构本身是一致的。5.2 能力门控规划主循环再写规划器主循环。这个循环做的事情是先用代价估计器判断剩余成本再决定是否进入实验选择。# 文件路径ccgp/planner.py from typing import List, Optional from ccgp.models import AgentState, Capability, CostEstimator class CapabilityGatedPlanner: def __init__(self, capabilities: List[Capability], cost_estimator: CostEstimator, gate_threshold: float 6.0): self.capabilities capabilities self.cost_estimator cost_estimator self.gate_threshold gate_threshold def gate_decision(self, state: AgentState) - str: 返回 proceed 或 upgrade 两种决策 remaining_cost self.cost_estimator.predict(state) if remaining_cost self.gate_threshold: return proceed, remaining_cost return upgrade, remaining_cost def select_experiment(self, state: AgentState) - Optional[Capability]: 在通过门控后选择一个能力来执行。这里用最简单的排序策略。 qualified [] for cap in self.capabilities: if cap.apply_condition(state): # 代价越小、成功率越高的能力优先 score cap.success_rate / max(cap.cost, 1e-6) qualified.append((score, cap)) qualified.sort(keylambda x: x[0], reverseTrue) return qualified[0][1] if qualified else None def plan(self, state: AgentState): decision, remaining_cost self.gate_decision(state) print(f[Gate] remaining_cost{remaining_cost:.2f}, decision{decision}) if decision upgrade: print([Plan] 当前能力不足进入能力提升或外部求助分支) return cap self.select_experiment(state) if cap is None: print([Plan] 没有可用能力需要补充能力集) return print(f[Plan] 选择能力: {cap.name})gate_decision是能力门控规划与普通贪心规划的最大区别它先检查全局剩余成本再决定是否进入动作选择。当剩余成本超过阈值时规划器不会硬着头皮选实验而是主动请求能力升级。5.3 对比实验Cost-to-Goal 与 Myopic 策略下面用一个模拟实验来对比能力门控规划Cost-to-Goal 策略和近视实验选择Myopic 策略的差异。# 文件路径ccgp/compare.py import random from ccgp.models import AgentState, CostEstimator from ccgp.planner import CapabilityGatedPlanner def run_myopic_simulation(steps: int 10) - int: 近视策略每次都选成功率最高的能力忽略剩余代价 total_cost 0 state AgentState({progress: 0.0}, {progress: 10.0}) for _ in range(steps): # 模拟一个近视的选择成功率高但收益低 success random.random() 0.9 if success: state.features[progress] 0.1 # 微小进展 total_cost 1 return state.features[progress], total_cost def run_cost_to_goal_simulation(steps: int 10) - int: 能力门控规划先估计剩余成本再决定是否执行高价值实验 capabilities [] # 定义一个高成本但必需的能力解决核心堵点 def core_condition(state: AgentState): return state.features[progress] 5.0 capabilities.append(type(Cap, (), { name: solve_core_bottleneck, apply_condition: core_condition, success_rate: 0.5, cost: 2.0 })()) estimator CostEstimator(base_cost3.0, penalty_coef0.5) planner CapabilityGatedPlanner(capabilities, estimator, gate_threshold10.0) state AgentState({progress: 0.0}, {progress: 10.0}) total_cost 0 for _ in range(steps): decision, remaining planner.gate_decision(state) if decision upgrade: total_cost 1 continue cap planner.select_experiment(state) if cap is None: continue success random.random() cap.success_rate if success: state.features[progress] 3.0 # 一次解决核心堵点进展大 total_cost cap.cost # 执行后校准代价估计器 estimator.update(state, cap.cost, state) return state.features[progress], total_cost random.seed(42) progress_m, cost_m run_myopic_simulation() progress_c, cost_c run_cost_to_goal_simulation() print(fMyopic - progress{progress_m:.1f}, total_cost{cost_m}) print(fCostToGo - progress{progress_c:.1f}, total_cost{cost_c})这段代码故意将一个能力设计成“高成本但解决核心瓶颈”另一个策略则不断选成功率 90% 的微小改进动作。如果多次运行你会发现近视策略在“单步成功率”上很好看但累计进展可能一直卡在原地而能力门控规划虽然在“单步成功率”上不如近视策略但它一旦选中核心能力就会显著缩短到达目标的距离。这段代码不是真实系统但是一个能帮助理解“为什么短视选择会卡住长任务”的最小模型。6. 效果验证怎么判断这套方案真的有效能力门控规划不是一把万能钥匙所以引入它之前需要设计一套能说明“好在哪里、坏在哪里”的验证流程。6.1 对比实验设计最直接的验证方式是设置两组 Agent对照组使用传统贪心/近视实验选择策略每次选择单步成功率最高的动作。实验组使用能力门控规划先估计 Cost-to-Goal再决定是否进入实验选择。两组 Agent 跑同一批任务记录四个指标指标说明观察目标任务完成率最终成功完成多少任务实验组应显著更高平均步数每个任务消耗的步骤数实验组应更少或至少不显著增加高风险动作占比高风险高价值动作在所有动作中的比例实验组应更高失败模式分析失败是卡死、重复、还是误判能力不足实验组应减少卡死型失败从理论上可以预期在长链路任务里实验组更可能提前感知“剩余代价过大”因此会更快触发能力升级或求助而不是在原地打转。6.2 离线数据回放除了在线对比实验还可以做离线数据回放。做法是收集一批已经执行过的 Agent 轨迹每条轨迹包含“状态→选择动作→结果→最终是否成功”。然后用你的代价估计器重新预测每个时间点的剩余成本并与实际完成路径的步数做对比。如果代价估计器预测的剩余成本与实际剩余步数之间的平均绝对误差不断下降说明 Cost-to-Goal Discovery 在学习一个有效的信号。相反如果误差居高不下问题多半出在状态特征表达上——当前的特征没有包含真正影响任务难度的影响因子。6.3 验证时容易踩的坑第一不能只看“任务完成率”这一个指标。一个把所有任务都判定为“能力不足”然后直接放弃的 Agent也可以在任务完成率上表现正常但它实际没有任何用处。需要同时观察“放弃率”和“平均步数”。第二不能使用和训练数据同分布的测试任务。代价估计器可能记住了任务难度而不是学会预测任务难度。测试任务应该覆盖新的工具组合、新的错误类型。第三不要忽略方差。能力门控规划引入了阈值判断这会让行为更偏向“不稳定”有时候一次任务快速完成另一次却直接放弃。记录多次运行的方差比记录单次最优值更有参考价值。7. 常见问题与排查思路能力门控规划在实际落地时会遇到一些很具体的问题。下面整理一份排查表。问题现象可能原因排查方式解决方案任务总是被门控拦截Agent 什么都不做门控阈值设置过严查看 remaining_cost 分布调高阈值或改成“分层门控”门控形同虚设Agent 依旧乱试代价估计器输出恒等于 0 或恒定值打印估计器输出观察是否随状态变化检查状态特征构建改为更有区分度的特征高风险动作仍然被拖延Cost-to-Goal 代价没有把“风险”计入检查代价计算公式在代价中加入风险项如不确定性 penalty单步成功率下降明显门控开始选择更高成本、更低成功率的动作对比实验组和对照组单步成功率确认全局任务完成率是否提升若没有调整能力评分公式执行结果与代价预测偏差大代价估计器没有及时校准检查 update 是否在每次执行后调用用 TD 或类似机制做持续校准多 Agent 场景下互相冲突每个 Agent 各自估计代价未共享信息查看是否存在共享的代价缓存设计统一的代价地图或共享知识库其中第一行是高频问题。人类的决策偏好是厌恶失败所以写门控逻辑时很容易把阈值设置得过于保守让 Agent 变成一个“只评估不行动”的专家。解决方法是把阈值做成动态的任务价值高时放宽风险可控时放宽早期探索阶段放宽。8. 工程最佳实践与落地建议能力门控规划要从原型走向生产环境不能只靠一个伪代码主循环还需要考虑数据、校准、安全边界和团队协作。8.1 代价模型不要从零凭空想Cost-to-Goal 的估计器最好从你的历史轨迹数据里训练而不是写死一个公式。如果你没有历史数据可以先从启发式规则起步比如“距离当前状态与目标状态的归一化差异”但必须规划好升级路径。我这里推荐一个落地顺序先用手写规则做代价估计快速跑通流程。收集 500 条以上历史轨迹训练一个小型回归模型。在回归模型达到一定准确率后替换手写规则并保留规则作为兜底。8.2 代价要拆维度而不是一个数字把 Cost-to-Goal 压缩成单一标量虽然简洁但在工程上会丢失信息。更合理的做法是拆成几个维度行动成本完成剩余动作所需的步骤数或算力。风险成本可能失败、需要重试的概率。信息成本还需要获取多少外部信息。外部依赖成本需要等待其他系统、人或服务响应的次数。门控决策时可以给每个维度设置独立阈值。比如“风险成本”超过阈值就切换到保守策略“信息成本”过高就切换到主动搜索策略。维度拆开后门控逻辑的透明度和可控性都会更好。8.3 能力边界不是固定值一个很容易犯的错是把“能力边界”看成静态配置某个模型能做什么不能做什么测试集上定下来就永远不变。实际上能力边界会随上下文动态变化。一个模型可能单独完成代码生成但面对“代码生成 数据库查询 部署”的复合任务时会因为上下文超长而能力骤降。因此能力门控的“能力置信度”应该是一个函数而不是常量。至少应该把上下文长度、工具数量、任务复杂度作为调节变量。8.4 把人类反馈纳入校准循环代价估计器如果只从自动执行结果中学习很容易把“看起来能走通的路径”误判为“低成本路径”。我强烈建议加入人类反馈信号用户取消了某个动作这是一个强负反馈。用户手动重试了某个动作说明代价被低估了。用户切换了工具说明当前能力集不合适能力清单需要调整。这些信号可以直接转化为校准更新的误差项让代价估计器更贴近真实业务。8.5 生产环境的安全边界能力门控规划会改变 Agent 的行为尤其是“升级”分支。如果 Agent 判断当前能力不足它可能会请求更多权限、调用更多外部资源这就有安全隐患。在生产环境接入时建议遵循最小权限原则能力清单里每一项能力绑定最小权限范围。门控触发“升级”分支时不直接授权而是进入“人工审批”流程。在测试环境完整验证新的能力提升路径再灰度到生产。每次门控决策记录日志包括剩余代价、阈值、决策理由、实际执行结果。如果你把 Agent 接入了数据库或支付链路务必在门控中设置“高风险动作二次确认”机制避免代价预测偏差导致不可逆操作。8.6 定期做“门控退化”检测一个很隐蔽的坑是门控逻辑运行久了会悄悄退化成一个“啥都不敢做”的保守过滤器。特别是当团队开始用历史数据训练代价模型时如果历史数据里失败案例很多模型会把几乎所有任务都预测为高成本。建议每个迭代周期做一次“门控退化”检测随机抽取一批你已经验证过的简单任务看门控是否正确放行。如果简单任务也开始被拦截说明代价估计器偏保守需要调整偏差项或重新采样历史数据。9. 总结与后续学习方向能力门控规划给我最大的启发是它把 Agent 规划的问题从“怎么生成更聪明的步骤”转移到了“怎么知道自己离目标有多远”。这个视角更适合解决长任务场景下 Agent 的慢性卡死问题。读完这篇文章你至少应该带走三点第一如果你的 Agent 经常“看起来在做事实际没进展”先不要急着换更大的模型先检查它的实验选择是不是太近视了。第二为规划器设计一个 Cost-to-Goal Discovery 模块比单纯优化“下一步动作生成”更接近问题的本质。第三能力门控不是“能不能做”的布尔判断而是一个包含代价估计、阈值决策、执行校准的完整循环。后续如果要继续深入可以沿着这几个方向走一是强化学习里的值函数估计和时序差分它们是 Cost-to-Goal Discovery 的理论底座二是蒙特卡洛树搜索MCTS的置信区间上界策略它比本文示例中的简单排序更鲁棒三是自适应规划器它可以在不同任务阶段动态切换 myopic 和 cost-aware 策略。这篇偏方法视角的文章建议收藏备用。等你真正在 Agent 项目里被“永远差一步才能完成任务”折磨的时候再回来看一眼会有更具体的体感。 
长河君 · 2026/8/28 11:55:56 · 阅读 1.2k 能力门控规划：解决AI Agent的短视与卡死问题
如果让你手下一个人去负责一条生产链路他每天都在汇报“我做了 A、做了 B、做了 C”但一周后核心业务指标没有任何变化你会怎么评价他当前不少 AI Agent 项目恰恰就处在这样一个状态规划模块能生成看起来合理的步骤能调用工具日志里每一步都有输出但整体任务就是卡着不动。于是大家把问题归结为“模型规划能力差”。可这个“差”到底差在哪里很多团队的答案是模型一直在选那些容易的、眼前收益高的实验却迟迟不去解决最关键的那个难点。这篇文章想聊一个偏前沿的规划思路——Capability-Gated Planning能力门控规划以及它背后的两个核心概念Cost-to-Goal Discovery到达目标的成本发现和 Myopic Experiment Selection近视实验选择。我的核心判断是限制 Agent 的往往不是“下一步该做什么”而是“它离目标到底还有多远”以及“哪些差距来自当前能力边界”。如果你正在做 LLM Agent、自动化决策链路或者任何一个需要自主规划的模块这篇文章能帮你重新审视规划器的设计方式。1. 这篇文章真正要解决的问题先描述一个非常常见的开发场景。你写了一个 Agent它在任务开始时先拆解目标然后逐项执行。第一天它去搜索资料第二天它生成了一段代码第三天它把代码跑通第四天它发现跑出的结果和预期不符。之后它开始频繁更换策略换提示词、换参数、换调用方式但一直停在“验证失败”这个环节。你去看日志发现它确实在做事情问题在于它做的实验都太“轻”了——搜索、改写、调用低风险 API这些实验单步成功率很高反馈也很好但累积下来并没有推动任务核心进展。这个现象就是 Myopic Experiment Selection翻译成“近视实验选择”很贴切。规划器在选择下一步实验时只关注“当前这个动作看起来能不能成功”而不关注“这个动作会不会显著缩短我到达目标的距离”。这篇文章要解决的问题不是“怎么生成步骤”而是“怎么让规划器知道自己和目标之间到底隔了多少成本”。传统规划思路是给定一个目标然后展开动作序列能力门控规划的思路正好反过来先评估当前能力距离目标有多远再决定要不要继续规划、选择什么类型的实验。它表面上是一种规划方法本质上是一种关于“代价感知”的训练与决策框架。为什么值得关注因为 LangChain 之类的 Agent 框架已经解决了很多“组织工具调用”的问题但进入复杂长任务后真正的瓶颈转移到了“如何选择行动序列”这件事上。而选择行动序列的关键不是你拥有多少工具而是你是否拥有一套能估计“到目标还需要多少代价”的机制。能力门控规划就是针对这个缺口提出的一种系统化方案。2. 核心概念拆解门控、代价与近视实验选择三个术语放在一起容易让人头晕但它们各自的角色其实很清楚。2.1 Capacity-Gated Planning先问“我能不能”再问“我怎么做”能力门控规划英文对应 Capability-Gated Planning核心思想是在规划动作之前先做一个关于“能力边界”的判断。普通 Agent 的行为链是目标 - 拆解步骤 - 执行步骤能力门控规划的行为链多了一层目标 - 判断“当前能力是否跨过了门槛” - 如果没跨过先做能力提升/外部求助 - 如果跨过再进入规划与执行这里的“能力”可以是一个模型的多项技能集合比如信息检索、代码生成、数学推理、环境交互也可以是一个团队的技能集合。门控的作用是过滤掉那些“当前能力明显达不到”的任务避免规划器在能力不匹配的路径上做无谓尝试。这个设计看起来简单但实际价值在于它把“能不能做”和“怎么做”拆成了两个独立问题。我们在 Agent 开发中经常看到模型被要求做一件它本身不具备能力的事它依然会硬着头皮生成一个规划然后在执行中反复失败。能力门控就是专门挡住这种情况。2.2 Cost-to-Goal Discovery发现的是“距离”不是“奖励”Cost-to-Goal Discovery直译是“到目标的成本发现”。这个词来自强化学习里的 cost-to-go 函数也有地方叫 value function。它的定义是从当前状态出发完成到目标状态所需的预期累计代价。注意这里的重点是“预期累计代价”不是“下一步的即时收益”。举个例子。你现在要开发一个推荐系统当前状态是“有历史数据但没有特征工程”目标是“上线一个离线评估 AUC 超过 0.75 的模型”。下一步实验可以是“补 10 个用户画像特征”也可以是“尝试 XGBoost 超参调优”。从及时反馈看后者很可能更快看到指标变化但从到达目标的长期代价看前者可能更关键。Cost-to-Goal Discovery 要计算的是这两种选择分别让“到目标的剩余代价”降低了多少。在经典的图搜索算法里这对应 A* 算法中的启发式代价也对应 Dijkstra 算法里的全局距离更新。Cost-to-Goal 不是告诉你“这个实验会不会成功”而是告诉你“这个实验是否让你离终点更近”。2.3 Myopic Experiment Selection只看眼前一步的选择策略近视实验选择是能力门控规划要修正的对象。“Myopic”在经济学里是“短视”的意思。一个近视的规划器在选择实验时通常只采用两种判断标准之一这个实验的成功概率高不高这个实验的即时回报大不大这两个标准有一个共同缺陷没有把“当前实验执行完之后后面还有多少路要走”纳入计算。于是它倾向于选择“看起来容易成功”的步骤而不是“对全局最必要”的步骤。我在接入很多 Agent 框架时观察到一个很典型的现象模型非常喜欢选择“读取文件”“查询数据库”“调用搜索 API”这类低风险操作因为单步成功率高而像“修改核心配置”“构造复杂 JSON 请求”“根据日志判断根因”这类高风险但高价值动作会被反复拖延甚至忽略。这就是近视实验选择在真实项目中的表现。特征Capability-Gated PlanningCost-to-Goal DiscoveryMyopic Experiment Selection回答的问题当前能力是否匹配任务当前状态离目标还有多远下一个实验该选哪个决策尺度任务级全局路径级单步级对失败的容忍高先过滤再执行中允许走弯路但会修正低尽量选易成功的动作失败典型表现任务被误判为不可达代价估计不准导致绕路完成大量低价值子任务适合场景能力边界明显的任务长链路、多阶段任务单步收益明确的短期任务3. 为什么“发现成本”比“选下一步实验”更本质很多做 Agent 的同学会困惑规划本身不就是“选下一步实验”吗为什么要把“发现成本”单独拿出来说因为“选下一步”和“知道还有多远”是两个层次的决策。一个只负责选下一步实验的规划器本质上是贪心算法。它每一步选一个“当前看起来最优”的动作但没有任何机制保证这些局部最优叠加起来是全局最优。在数学上贪心算法只有在满足特定条件时才能得到最优解在真实 Agent 任务里几乎不存在这些条件。而能力门控规划真正关心的是先建立一个“代价地图”。如果你知道从当前状态到目标的最低预期代价是 7 个单位那么任何代价超过 7 的动作都会被淘汰如果你只有“当前动作成功率”而没有“剩余成本”你就没有判断依据。我用一个生活中的类比来说明。假设你要从一座荒岛出发走到岛的另一端。你有两个选择一是花 10 分钟把路边容易捡到的野果都采下来二是花 30 分钟把断桥修好。采野果的即时收益很高你马上有食物了但修桥才能让你继续前进。一个只做“下一步实验选择”的规划器会一直采野果因为它每步都在获得即时奖励。而一个先做“成本发现”的规划器会知道修完桥后剩余路程的代价是 20 分钟不修桥无论采多少野果剩余路程都是无穷大。这个类比可以原封不动映射到 Agent 任务里。Agent 在规划时需要的不是“哪个工具调用起来更顺手”而是“哪条路径会让到达目标的剩余代价显著下降”。Cost-to-Goal Discovery 还提供了一个非常实用的视角把“不确定性”计入代价。从状态 A 到目标如果两条路径的总代价相同但一条路径的方差更大那么稳健的做法是选方差小的路径。这一点在 LLM Agent 里特别重要因为大模型生成动作的随机性很高同样的路径可能这次成功、下次失败。把不确定性纳入代价估计门控规划的质量会明显提升。4. 能力门控规划的核心流程拆解下面把能力门控规划拆成四个阶段。这样做不是为了让你立刻去实现一个完整框架而是为了帮助你理解“门控”这个词到底是在哪一层发生的。4.1 阶段一构建能力清单第一阶段是建立“能力清单”。这里的能力包括工具调用能力、模型推理能力、外部知识获取能力甚至包括“在失败 n 次后是否切换策略”的元能力。在这个阶段需要回答的问题不是“我应该怎么解决这个任务”而是“我目前拥有哪些解决这个任务的资源”。实际操作中你应该为每一项能力标注三个属性能力名称比如“代码执行器”适用条件比如“需要 Python 3.8”置信度比如“在这个领域内成功率约 80%”这里容易犯的错误是只写“有什么工具”不写“工具能保证什么”。能力清单如果没有置信度信息后面的门控判断就是空谈。4.2 阶段二估计 Cost-to-Goal第二阶段是关键。你需要一个代价估计器它输入当前状态和目标输出一个标量预期剩余代价。这个估计器可以从两个方向构建。第一种是人类专家规则把任务拆成若干阶段给每个阶段打一个预期耗时或失败风险然后求和。这种方法在小规模任务里可用但扩展性差。第二种是从历史轨迹中学习记下大量“状态-动作-结果-成本”四元组训练一个小型回归模型来预测“从当前状态到目标还需要多少步”或“还需要付出多少代价”。这是更工程化的做法也是后续章节里我会给出伪代码的部分。代价估计器输出的含义要定义清楚。它可以是“预期步数”也可以是“预期试错次数”还可以是“预期风险损失”。我建议团队在初期把代价定义成“预期剩余步数”因为它最容易理解、也最容易验证。4.3 阶段三能力门控决策拿到能力清单和代价估计后就到了“门控”所在的阶段。门控逻辑可以写得很简单if 预计剩余代价 可接受阈值: 进入详细规划与执行 else: 不进入当前规划触发能力提升或外部求助但这个简单逻辑背后有三个要点。第一阈值不是固定的。它随着任务价值、可用算力、用户耐心动态变化。任务价值高时阈值可以放宽算力紧张时阈值应当收紧。第二门控要区分“能力不足”和“代价过高”。如果模型判断自己“完全不会做”应该走“能力提升”分支如果模型判断“可以做到但代价很大”应该走“资源申请”分支。两种情况的处理方式完全不同。第三门控不能让执行变得过于保守。如果任何高代价任务都被门控拦截Agent 就退化成一个只做简单任务的工具这违背了加入规划模块的初衷。4.4 阶段四执行与代价校准执行阶段不是终点。执行过程中会产生真实的代价反馈这些反馈要用来更新代价估计器。这一步非常重要。代价估计很少能一次算准它需要不断校准。校准的机制可以参照强化学习里的 Temporal Difference时间差分思想新的代价估计 当前估计 学习率 * (实际支付代价 未来代价估计 - 当前估计)用大白话说如果你预测从 A 到目标要 3 步实际执行后发现从 A 到 B 用了 1 步而从 B 到目标又需要 4 步那么你会把 A 的代价估计从 3 修正成更接近 145 的值。这个更新公式就是 Cost-to-Goal Discovery 从理论走向工程的关键。5. 完整示例一个最小能力门控规划实现本章用一个很小的 Python 示例演示能力门控规划的主干逻辑。它不会依赖任何特定 Agent 框架你也可以把它改造成自己的规划器原型。5.1 定义核心数据结构先定义状态、能力和代价估计器的数据结构。# 文件路径ccgp/models.py from dataclasses import dataclass, field from typing import Dict, List, Callable, Optional dataclass class Capability: Agent 拥有的一项能力 name: str apply_condition: Callable[[AgentState], bool] success_rate: float 0.5 cost: float 1.0 dataclass class AgentState: 当前 Agent 状态可以简单理解为一组特征字典 features: Dict[str, float] goal_features: Dict[str, float] field(default_factorydict) def distance_to_goal(self) - float: 简化版距离计算当前特征与目标特征的差异 if not self.goal_features: return 999.0 diff 0.0 for key, target_value in self.goal_features.items(): cur_value self.features.get(key, 0.0) diff abs(cur_value - target_value) return diff dataclass class CostEstimator: 从状态特征预测到达目标剩余代价的估计器 base_cost: float 5.0 penalty_coef: float 0.2 def predict(self, state: AgentState) - float: # 先用距离作为代理指标真实项目中可以换成训练好的回归模型 return self.base_cost self.penalty_coef * state.distance_to_goal() def update(self, current_state: AgentState, actual_cost: float, next_state: AgentState, learning_rate: float 0.1) - None: 使用 TD 思想校准代价估计 predicted_cost self.predict(current_state) future_cost self.predict(next_state) td_target actual_cost future_cost # 调整 base_cost等于把误差反向传播到基础常数上 error td_target - predicted_cost self.base_cost max(0.1, self.base_cost learning_rate * error)这段代码里distance_to_goal()是最朴素的代价度量方式。真正的项目里它可能是一个通过历史轨迹训练出来的回归模型但数据结构本身是一致的。5.2 能力门控规划主循环再写规划器主循环。这个循环做的事情是先用代价估计器判断剩余成本再决定是否进入实验选择。# 文件路径ccgp/planner.py from typing import List, Optional from ccgp.models import AgentState, Capability, CostEstimator class CapabilityGatedPlanner: def __init__(self, capabilities: List[Capability], cost_estimator: CostEstimator, gate_threshold: float 6.0): self.capabilities capabilities self.cost_estimator cost_estimator self.gate_threshold gate_threshold def gate_decision(self, state: AgentState) - str: 返回 proceed 或 upgrade 两种决策 remaining_cost self.cost_estimator.predict(state) if remaining_cost self.gate_threshold: return proceed, remaining_cost return upgrade, remaining_cost def select_experiment(self, state: AgentState) - Optional[Capability]: 在通过门控后选择一个能力来执行。这里用最简单的排序策略。 qualified [] for cap in self.capabilities: if cap.apply_condition(state): # 代价越小、成功率越高的能力优先 score cap.success_rate / max(cap.cost, 1e-6) qualified.append((score, cap)) qualified.sort(keylambda x: x[0], reverseTrue) return qualified[0][1] if qualified else None def plan(self, state: AgentState): decision, remaining_cost self.gate_decision(state) print(f[Gate] remaining_cost{remaining_cost:.2f}, decision{decision}) if decision upgrade: print([Plan] 当前能力不足进入能力提升或外部求助分支) return cap self.select_experiment(state) if cap is None: print([Plan] 没有可用能力需要补充能力集) return print(f[Plan] 选择能力: {cap.name})gate_decision是能力门控规划与普通贪心规划的最大区别它先检查全局剩余成本再决定是否进入动作选择。当剩余成本超过阈值时规划器不会硬着头皮选实验而是主动请求能力升级。5.3 对比实验Cost-to-Goal 与 Myopic 策略下面用一个模拟实验来对比能力门控规划Cost-to-Goal 策略和近视实验选择Myopic 策略的差异。# 文件路径ccgp/compare.py import random from ccgp.models import AgentState, CostEstimator from ccgp.planner import CapabilityGatedPlanner def run_myopic_simulation(steps: int 10) - int: 近视策略每次都选成功率最高的能力忽略剩余代价 total_cost 0 state AgentState({progress: 0.0}, {progress: 10.0}) for _ in range(steps): # 模拟一个近视的选择成功率高但收益低 success random.random() 0.9 if success: state.features[progress] 0.1 # 微小进展 total_cost 1 return state.features[progress], total_cost def run_cost_to_goal_simulation(steps: int 10) - int: 能力门控规划先估计剩余成本再决定是否执行高价值实验 capabilities [] # 定义一个高成本但必需的能力解决核心堵点 def core_condition(state: AgentState): return state.features[progress] 5.0 capabilities.append(type(Cap, (), { name: solve_core_bottleneck, apply_condition: core_condition, success_rate: 0.5, cost: 2.0 })()) estimator CostEstimator(base_cost3.0, penalty_coef0.5) planner CapabilityGatedPlanner(capabilities, estimator, gate_threshold10.0) state AgentState({progress: 0.0}, {progress: 10.0}) total_cost 0 for _ in range(steps): decision, remaining planner.gate_decision(state) if decision upgrade: total_cost 1 continue cap planner.select_experiment(state) if cap is None: continue success random.random() cap.success_rate if success: state.features[progress] 3.0 # 一次解决核心堵点进展大 total_cost cap.cost # 执行后校准代价估计器 estimator.update(state, cap.cost, state) return state.features[progress], total_cost random.seed(42) progress_m, cost_m run_myopic_simulation() progress_c, cost_c run_cost_to_goal_simulation() print(fMyopic - progress{progress_m:.1f}, total_cost{cost_m}) print(fCostToGo - progress{progress_c:.1f}, total_cost{cost_c})这段代码故意将一个能力设计成“高成本但解决核心瓶颈”另一个策略则不断选成功率 90% 的微小改进动作。如果多次运行你会发现近视策略在“单步成功率”上很好看但累计进展可能一直卡在原地而能力门控规划虽然在“单步成功率”上不如近视策略但它一旦选中核心能力就会显著缩短到达目标的距离。这段代码不是真实系统但是一个能帮助理解“为什么短视选择会卡住长任务”的最小模型。6. 效果验证怎么判断这套方案真的有效能力门控规划不是一把万能钥匙所以引入它之前需要设计一套能说明“好在哪里、坏在哪里”的验证流程。6.1 对比实验设计最直接的验证方式是设置两组 Agent对照组使用传统贪心/近视实验选择策略每次选择单步成功率最高的动作。实验组使用能力门控规划先估计 Cost-to-Goal再决定是否进入实验选择。两组 Agent 跑同一批任务记录四个指标指标说明观察目标任务完成率最终成功完成多少任务实验组应显著更高平均步数每个任务消耗的步骤数实验组应更少或至少不显著增加高风险动作占比高风险高价值动作在所有动作中的比例实验组应更高失败模式分析失败是卡死、重复、还是误判能力不足实验组应减少卡死型失败从理论上可以预期在长链路任务里实验组更可能提前感知“剩余代价过大”因此会更快触发能力升级或求助而不是在原地打转。6.2 离线数据回放除了在线对比实验还可以做离线数据回放。做法是收集一批已经执行过的 Agent 轨迹每条轨迹包含“状态→选择动作→结果→最终是否成功”。然后用你的代价估计器重新预测每个时间点的剩余成本并与实际完成路径的步数做对比。如果代价估计器预测的剩余成本与实际剩余步数之间的平均绝对误差不断下降说明 Cost-to-Goal Discovery 在学习一个有效的信号。相反如果误差居高不下问题多半出在状态特征表达上——当前的特征没有包含真正影响任务难度的影响因子。6.3 验证时容易踩的坑第一不能只看“任务完成率”这一个指标。一个把所有任务都判定为“能力不足”然后直接放弃的 Agent也可以在任务完成率上表现正常但它实际没有任何用处。需要同时观察“放弃率”和“平均步数”。第二不能使用和训练数据同分布的测试任务。代价估计器可能记住了任务难度而不是学会预测任务难度。测试任务应该覆盖新的工具组合、新的错误类型。第三不要忽略方差。能力门控规划引入了阈值判断这会让行为更偏向“不稳定”有时候一次任务快速完成另一次却直接放弃。记录多次运行的方差比记录单次最优值更有参考价值。7. 常见问题与排查思路能力门控规划在实际落地时会遇到一些很具体的问题。下面整理一份排查表。问题现象可能原因排查方式解决方案任务总是被门控拦截Agent 什么都不做门控阈值设置过严查看 remaining_cost 分布调高阈值或改成“分层门控”门控形同虚设Agent 依旧乱试代价估计器输出恒等于 0 或恒定值打印估计器输出观察是否随状态变化检查状态特征构建改为更有区分度的特征高风险动作仍然被拖延Cost-to-Goal 代价没有把“风险”计入检查代价计算公式在代价中加入风险项如不确定性 penalty单步成功率下降明显门控开始选择更高成本、更低成功率的动作对比实验组和对照组单步成功率确认全局任务完成率是否提升若没有调整能力评分公式执行结果与代价预测偏差大代价估计器没有及时校准检查 update 是否在每次执行后调用用 TD 或类似机制做持续校准多 Agent 场景下互相冲突每个 Agent 各自估计代价未共享信息查看是否存在共享的代价缓存设计统一的代价地图或共享知识库其中第一行是高频问题。人类的决策偏好是厌恶失败所以写门控逻辑时很容易把阈值设置得过于保守让 Agent 变成一个“只评估不行动”的专家。解决方法是把阈值做成动态的任务价值高时放宽风险可控时放宽早期探索阶段放宽。8. 工程最佳实践与落地建议能力门控规划要从原型走向生产环境不能只靠一个伪代码主循环还需要考虑数据、校准、安全边界和团队协作。8.1 代价模型不要从零凭空想Cost-to-Goal 的估计器最好从你的历史轨迹数据里训练而不是写死一个公式。如果你没有历史数据可以先从启发式规则起步比如“距离当前状态与目标状态的归一化差异”但必须规划好升级路径。我这里推荐一个落地顺序先用手写规则做代价估计快速跑通流程。收集 500 条以上历史轨迹训练一个小型回归模型。在回归模型达到一定准确率后替换手写规则并保留规则作为兜底。8.2 代价要拆维度而不是一个数字把 Cost-to-Goal 压缩成单一标量虽然简洁但在工程上会丢失信息。更合理的做法是拆成几个维度行动成本完成剩余动作所需的步骤数或算力。风险成本可能失败、需要重试的概率。信息成本还需要获取多少外部信息。外部依赖成本需要等待其他系统、人或服务响应的次数。门控决策时可以给每个维度设置独立阈值。比如“风险成本”超过阈值就切换到保守策略“信息成本”过高就切换到主动搜索策略。维度拆开后门控逻辑的透明度和可控性都会更好。8.3 能力边界不是固定值一个很容易犯的错是把“能力边界”看成静态配置某个模型能做什么不能做什么测试集上定下来就永远不变。实际上能力边界会随上下文动态变化。一个模型可能单独完成代码生成但面对“代码生成 数据库查询 部署”的复合任务时会因为上下文超长而能力骤降。因此能力门控的“能力置信度”应该是一个函数而不是常量。至少应该把上下文长度、工具数量、任务复杂度作为调节变量。8.4 把人类反馈纳入校准循环代价估计器如果只从自动执行结果中学习很容易把“看起来能走通的路径”误判为“低成本路径”。我强烈建议加入人类反馈信号用户取消了某个动作这是一个强负反馈。用户手动重试了某个动作说明代价被低估了。用户切换了工具说明当前能力集不合适能力清单需要调整。这些信号可以直接转化为校准更新的误差项让代价估计器更贴近真实业务。8.5 生产环境的安全边界能力门控规划会改变 Agent 的行为尤其是“升级”分支。如果 Agent 判断当前能力不足它可能会请求更多权限、调用更多外部资源这就有安全隐患。在生产环境接入时建议遵循最小权限原则能力清单里每一项能力绑定最小权限范围。门控触发“升级”分支时不直接授权而是进入“人工审批”流程。在测试环境完整验证新的能力提升路径再灰度到生产。每次门控决策记录日志包括剩余代价、阈值、决策理由、实际执行结果。如果你把 Agent 接入了数据库或支付链路务必在门控中设置“高风险动作二次确认”机制避免代价预测偏差导致不可逆操作。8.6 定期做“门控退化”检测一个很隐蔽的坑是门控逻辑运行久了会悄悄退化成一个“啥都不敢做”的保守过滤器。特别是当团队开始用历史数据训练代价模型时如果历史数据里失败案例很多模型会把几乎所有任务都预测为高成本。建议每个迭代周期做一次“门控退化”检测随机抽取一批你已经验证过的简单任务看门控是否正确放行。如果简单任务也开始被拦截说明代价估计器偏保守需要调整偏差项或重新采样历史数据。9. 总结与后续学习方向能力门控规划给我最大的启发是它把 Agent 规划的问题从“怎么生成更聪明的步骤”转移到了“怎么知道自己离目标有多远”。这个视角更适合解决长任务场景下 Agent 的慢性卡死问题。读完这篇文章你至少应该带走三点第一如果你的 Agent 经常“看起来在做事实际没进展”先不要急着换更大的模型先检查它的实验选择是不是太近视了。第二为规划器设计一个 Cost-to-Goal Discovery 模块比单纯优化“下一步动作生成”更接近问题的本质。第三能力门控不是“能不能做”的布尔判断而是一个包含代价估计、阈值决策、执行校准的完整循环。后续如果要继续深入可以沿着这几个方向走一是强化学习里的值函数估计和时序差分它们是 Cost-to-Goal Discovery 的理论底座二是蒙特卡洛树搜索MCTS的置信区间上界策略它比本文示例中的简单排序更鲁棒三是自适应规划器它可以在不同任务阶段动态切换 myopic 和 cost-aware 策略。这篇偏方法视角的文章建议收藏备用。等你真正在 Agent 项目里被“永远差一步才能完成任务”折磨的时候再回来看一眼会有更具体的体感。