A9 · Agent 如何规划任务并进行推理？ - Planning & Reasoning
所属知识库：Agent 全栈技术地图
所属领域：02 · Agent
所属章节：02 · Agent 的能力由哪些部分构成？ - Internal Architecture
文档类型：技术原理与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：Agent 如何将目标转化为可执行的行动计划？模型推理、状态空间搜索、任务分解、行动选择与动态重规划分别解决什么问题？如何表示目标、前置条件、依赖、证据和不确定性，如何将规划结果交给运行时安全执行，并通过工程实验评估计划的有效性与可靠性？
专题导读
在 A7 · Tools 中，我们研究 Agent 如何提出、授权并执行工具调用；在 A8 · Skills 中，我们研究如何封装和复用专业任务方法。A9 进一步研究一个更根本的问题：面对一个尚未完成的目标，系统如何确定应该做什么、先做什么、何时改变计划，以及如何判断目标已经实现？
本篇将 Reasoning（推理）理解为根据可用信息形成中间判断、候选解释或行动依据的计算过程，将 Planning（规划）理解为根据目标、当前状态和行动模型，构造满足约束的行动序列或行动策略。两者相互依赖但并不等同。大语言模型能够生成看似合理的计划文本，不代表计划可执行；规划器能够搜索合法行动序列，也不意味着它理解自然语言或能正确处理开放世界事实。
本篇同时研究经典规划与现代 LLM Agent。经典规划提供状态、动作、目标和搜索的精确定义；LLM 提供开放任务的语义理解、候选动作生成与启发式判断；运行时提供状态、授权、工具执行和反馈。它们可以组合，也可以根据任务复杂度择一使用。工程示例使用 Python 标准库验证符号规划、执行前条件检查、反馈驱动重规划、权限和预算，不声称验证了真实模型的推理能力。
01 · 概念定位：推理、规划、决策与执行
1.1 四个概念的边界
| 概念 | 主要输入 | 主要输出 | 典型问题 |
|---|---|---|---|
| Reasoning 推理 | 问题、事实、证据、约束 | 判断、解释、候选方案、置信信息 | 当前证据说明什么？缺少什么？ |
| Planning 规划 | 目标、初始状态、动作模型、约束 | 行动序列、任务图或条件策略 | 如何到达目标状态？ |
| Decision / Policy 行动选择 | 当前观测、状态、计划、预算 | 下一步行动或停止 | 现在应该执行哪一步？ |
| Execution 执行 | 已授权行动及参数 | 工具结果、外部副作用、状态变化 | 行动是否真的发生？ |
例如研究助理收到“比较两种 Agent 框架的恢复机制，提交带来源的报告”。推理需要识别“恢复机制”可能涉及 checkpoint、durable execution、retry 与 side effects；规划需要安排查找官方文档、提取证据、形成对照、验证结论的依赖顺序；行动选择需要决定此刻搜索哪个主题；执行器则真正访问文档、写入文件并返回结果。模型生成 search(query=...) 是行动提议，不是已执行的行动。
1.2 计划不等于思维链
自然语言“先检索，再分析，最后写作”是高层意图描述，不一定包含可验证的前置条件、输入输出和失败处理。模型生成的内部推理文本也不能直接视为可靠执行轨迹；系统应以可观察的工具调用、状态变更、证据记录、验收结果判断行为。规划可以采用结构化任务图或符号动作，而不必依赖展示模型的私有推理过程。
1.3 何时不需要显式规划
一步即可完成、行动确定且成本低的任务通常直接执行即可。步骤稳定的任务可采用普通函数或固定工作流。显式规划更适合：目标包含多项依赖、行动代价差异大、工具结果不确定、存在需要协调的资源或审批、执行过程中需要根据反馈调整路径。引入规划器会增加状态建模、计算和调试成本，因此应依据任务结构而非“Agent”标签决定。
02 · 形式化模型：状态、动作、目标和策略
2.1 确定性规划问题
经典规划可以表示为：
其中 S 是状态集合，A 是动作集合，T:S×A→S 是状态转移函数，s₀ 是初始状态，G⊆S 是目标状态集合，c(s,a) 是执行代价。规划器寻找 π=(a₁,…,aₙ)，使得从 s₀ 依次应用动作后进入 G；如果优化成本，则最小化 Σc(sᵢ,aᵢ)。
在一个简化研究任务中，可用命题集合表示状态：
s0 = {task_defined}
goal = {report_verified}
search: pre={task_defined} add={sources_found}
read: pre={sources_found} add={evidence_collected}
draft: pre={evidence_collected} add={report_drafted}
verify: pre={report_drafted,evidence_collected} add={report_verified}这是 STRIPS 风格的命题状态表示。动作可包含前置条件 pre、添加效果 add 和删除效果 delete：
该模型的优点是前置条件可机检、状态转移可追踪、搜索可复现；限制是开放世界中的“证据可信”“报告充分”难以用简单布尔命题完整表达。它应被视为工程抽象，不是现实任务的全部语义。
2.2 不完全观测与不确定性
真实 Agent 通常不知道环境完整状态。网页可能失效，工具结果可能错误，文件可能被外部修改，API 调用可能超时却已产生副作用。此时应区分：世界状态 s、观测 o、Agent 维护的信念或工作状态 b。在部分可观测决策模型中，策略可以写成 π(b)→a，依据观测更新信念 b' = update(b,a,o)。
并非所有工程系统都需要实现完整 POMDP。更常见的实用做法是：维护已知事实与证据来源、记录不确定状态、在关键动作前重新读取环境、对不可逆操作进行授权和验证。形式化模型的价值在于提醒开发者：计划基于的是当时可用的状态描述，而不是永远正确的现实。
2.3 目标与约束
目标可以分为：最终产物（生成报告）、状态条件（所有关键结论均有来源）、过程约束（不访问禁止域名）、资源约束（最多 20 次工具调用）、授权约束（未经审批不得发布）。这些条件不能全部混为一条自然语言指令。
建议将任务契约分为 goal_predicates、acceptance_tests、hard_constraints、budgets、approval_gates。其中权限与审批必须由执行环境强制实施，不能仅依赖规划器“记住”限制。
03 · 规划问题的表示：序列、DAG 与层级任务
3.1 线性计划
线性计划 search → read → draft → verify 便于执行和审计，但可能过度指定顺序：两个独立来源的阅读本可并行。更重要的是，若 read 失败，线性计划需要额外的异常分支才能继续。
3.2 任务依赖图（DAG）
┌─ search_source_A ─ read_A ─┐
research ──┤ ├─ compare ─ draft ─ verify
└─ search_source_B ─ read_B ─┘DAG 节点应至少包含 task_id、输入引用、预期产物、依赖、状态和验收条件；边表达“必须先完成”而非纯展示顺序。执行时应避免把“依赖已完成”误认为“输出可用”：节点成功状态还需对应实际产物校验。存在循环迭代时，通常使用“DAG + 重试/重新生成任务图”或状态机，而非强行把所有反馈循环塞进无环图。
3.3 层级任务网络（HTN）
HTN 将高层任务逐步分解为子任务和可执行动作。例如 produce_research_report 可以按任务方法分解为 collect_evidence → compare → write → verify。与单纯在状态空间搜索不同，HTN 通过预先编码的领域方法限制搜索空间，适合专业流程较稳定的场景。代价是方法库的维护成本与领域外泛化限制。A8 Skills 中的可复用研究方法可以作为 HTN 分解规则的来源，但Skill 并不自动等于 HTN 方法。
3.4 条件计划与策略
如果搜索无结果，应改写查询；如果证据冲突，应追加验证；如果用户拒绝审批，应终止发布。这些场景无法用单条固定序列充分表示。条件计划包含观察分支；更一般的策略直接依据当前状态选择动作。现代 Agent 常采用“短计划 + 执行一步 + 观察 + 更新”的闭环，减少对远期环境的过度假设。
04 · 经典规划算法：搜索如何工作
4.1 广度优先搜索（BFS）
BFS 将状态作为图节点、动作作为边，从初始状态逐层扩展，首次找到目标即返回计划。在有限状态、单位步成本下，BFS 能找到步数最少的计划；如果动作成本不同，它不保证总成本最小。空间开销通常很高，分支因子为 b、最浅目标深度为 d 时，时间和空间在典型树搜索分析中可达 O(b^d) 量级。
4.2 Dijkstra / Uniform-Cost Search
当动作代价不同，例如调用昂贵模型与读取本地缓存的成本差异，按累计代价扩展状态可寻找最低成本计划。对非负边成本成立；若存在大量等价状态，需要状态去重和更严格的资源限制。
4.3 A* 与启发式
A* 按 f(n)=g(n)+h(n) 选择候选状态：g 为已花成本，h 为到目标的估计成本。在满足相应条件的图搜索实现中，可采纳的启发式（不高估剩余成本）可保证最优性；使用不满足条件的启发式则可能牺牲最优性换取速度。LLM 生成的“距离目标还有几步”一般不能自动视为可采纳启发式。
4.4 前向、后向与部分序规划
前向规划从当前状态尝试合法动作；后向规划从目标条件推导哪些动作能够满足它，再递归检查前置条件；部分序规划只确定必要的先后约束，保留可并行空间。不同方法适合不同的动作模型，开放环境的难点往往不是搜索算法本身，而是动作效果与目标条件难以精确建模。
4.5 搜索与模型推理的互补
LLM 可以把自然语言任务转换为候选动作、前置条件或任务分解，但可能遗漏隐含依赖、虚构工具能力或给出不一致约束。符号规划器可检查其形式结构是否可执行，但不能凭空保证自然语言转译正确。可采用：模型生成候选结构 → schema 校验 → 环境事实核对 → 搜索或约束检查 → 执行反馈。每一层解决不同类型的错误。
05 · LLM Agent 的规划技术路线
5.1 直接生成计划（Plan-first）
模型一次性输出结构化任务列表，然后执行器逐项执行。优点是全局结构清晰、容易展示和审批；缺点是长计划容易受错误假设影响，执行中需要检查依赖是否仍成立。适合可预测、任务分解明确的场景。
5.2 ReAct：推理与行动交替
ReAct（Yao 等，2022/2023）将语言模型生成的行动决策与外部观察交织，强调根据工具反馈继续行动。它更接近局部在线决策，不保证产生全局最优计划。研究时应区分论文提出的轨迹模式与具体产品是否显示或存储内部推理内容；工程系统可以只记录行动和观察等可审计事件。
5.3 Plan-and-Execute
规划器先形成任务分解，执行器逐步完成，必要时由重规划器修订计划。优势是将全局分解与局部执行分开；风险是规划器与执行器使用不同状态快照，导致“计划有效、执行已过时”。因此需要明确计划版本、节点状态、执行结果与重规划触发条件。
5.4 Tree of Thoughts / 搜索候选思路
Tree of Thoughts（Yao 等，2023）探索多个候选中间步骤并进行评价与回溯，适合具有可评估中间状态的复杂问题。但候选数量、深度和评价调用会带来明显计算开销；若评价器不可靠，搜索可能系统性放大错误判断。不能简单推断“思路树越大，任务越可靠”。
5.5 LLM + 符号规划器
将 LLM 用于提取任务约束或生成领域动作描述，再由 PDDL/STRIPS 风格规划器搜索。此路线可以获得较强的结构验证能力，但瓶颈转移到语义落地：生成的动作前置条件是否真实？工具的副作用是否完整建模？环境是否仍满足模型假设？必须加入执行前校验与反馈修正。
5.6 反思、反馈与重规划
Reflexion（Shinn 等，2023）讨论通过语言反馈改进后续尝试；这不等于任意“反思提示”都能提升性能。工程上应区分：执行反馈（工具返回 404）、验证反馈（来源不支持结论）、策略反馈（计划代价过高）、人工反馈（审批拒绝）。只有反馈被转化为可执行的状态更新、约束调整或新行动，才形成可操作的改进闭环。
06 · 从目标到计划：可实施的数据契约
建议将自然语言任务转化为结构化对象，而非只存储一段计划文字。以下是概念性 JSON 示例，并非特定框架现行 API：
{
"task_id": "research-001",
"goal": {"artifact": "comparison_report", "requires_citations": true},
"constraints": {"max_tool_calls": 20, "publish_requires_approval": true},
"plan_version": 3,
"steps": [
{"id": "s1", "kind": "search", "depends_on": [], "output": "source_refs"},
{"id": "s2", "kind": "read", "depends_on": ["s1"], "output": "evidence"},
{"id": "s3", "kind": "draft", "depends_on": ["s2"], "output": "report_draft"},
{"id": "s4", "kind": "verify", "depends_on": ["s3"], "output": "verification_result"}
]
}核心不变量包括：节点 ID 唯一；依赖引用有效且无不允许的循环；步骤类型属于已注册动作集合；每个动作的参数满足 schema；目标与验收条件可判定；计划版本与执行快照绑定；高风险动作经过独立授权。计划生成器只能提出动作，不能通过编写 "approved": true 自行授予权限。
07 · 规划器与运行时的职责分离
用户任务 ──► Task Contract ──► Planner / Policy
│ 候选计划/行动
▼
Plan Validator
│ 结构与依赖检查
▼
Runtime Scheduler
│ 当前状态/预算
▼
Policy / Approval Gate
│ 授权结果
▼
Tool Executor
│ 真实执行结果
▼
Observation + State Store
│
┌────────────┴────────────┐
▼ ▼
验收通过 需继续/重规划
│ │
▼ └──► Planner
完成规划器可以建议 delete_file，但不能绕过权限；可以预测某个动作会生成证据，但不能直接将预测写成“已获得证据”；可以提出完成，但应由独立验收逻辑确认。状态存储必须区分 planned、ready、running、succeeded、failed、blocked、cancelled，避免计划与执行状态混淆。
当系统具备异步任务和外部副作用时，running 状态可能因超时而变成 unknown_outcome：此时直接重试可能重复发送邮件或重复扣款。规划逻辑必须与 A7 的幂等策略、A10 的授权约束和 Agent System 的执行恢复机制配合。
08 · 动态重规划：触发、范围与状态一致性
8.1 何时重规划
典型触发器包括：动作失败；新证据推翻旧假设；资源预算不足；依赖产物无效；用户改变目标；权限被拒；外部环境发生变化。并非每次工具返回都需要全局重规划：正常完成节点通常只需推进下一个就绪节点。
8.2 局部修补与全局重规划
局部修补仅修改失败节点及其下游依赖，通常成本较低；全局重规划重新搜索完整路径，适合目标、约束或核心环境假设发生变化。二者的选择取决于受影响的依赖范围、重新计算成本与执行风险。对已经产生的不可逆副作用，重规划不能假设“撤销计划”就等于撤销现实操作。
8.3 防止无限重规划
必须设置最大模型调用次数、最大动作次数、重复计划检测、总成本预算、时间截止和人工升级条件。特别是“搜索无结果→换关键词→搜索无结果”可能无限循环。可记录 (goal, state_fingerprint, action)，在状态未发生有效变化时限制重复行动；但状态指纹不能代替业务级幂等键。
8.4 状态一致性
规划器读取 state_version=v5 后，执行器可能已经把状态更新到 v6。执行前应检查依赖和版本，必要时采用乐观并发控制（例如 compare-and-swap）或重新规划。对于外部工具，校验与执行之间仍可能发生竞态，必须结合服务端条件请求、幂等键或事务语义，而不能只依靠本地检查。
09 · 规划质量：不是计划越长越好
9.1 可行性与正确性
计划是否满足动作前置条件？是否依赖不存在的工具？是否包含未授权操作？是否满足目标？符号规划中的可达性不等于现实可执行性，因为动作模型可能不完整。
9.2 效率与资源
可衡量动作数、模型调用数、token 成本、工具成本、执行延迟、重复工作比例与预算超限率。最短步数、最低金钱成本和最低失败风险可能对应不同计划，不能混为单一最优指标。
9.3 鲁棒性与恢复
应在证据缺失、工具超时、环境变化、权限拒绝、部分成功、状态过期等场景下观察：能否检测异常、能否正确更新状态、能否安全重试、能否停止或请求人工介入。
9.4 结果与证据质量
对研究助理，报告是否完成不是唯一目标；还要验证关键论断是否有来源支持、引用是否对应原文、是否区分事实与推断。规划器可以安排 verify 步骤，但验证质量依赖实际检验器和证据，不能由计划文本自行保证。
10 · 工程实验：可运行的符号规划与反馈重规划
配套文件 A9-Agent-Planning-and-Reasoning-v1.1-demo.py，Python 3 标准库（含 3.9；使用 from __future__ import annotations）。代码实现一个最小 STRIPS 风格动作模型、BFS 规划器、逐步执行循环、执行前权限检查、模拟证据失效和反馈驱动重规划。
10.1 关键实现
@dataclass(frozen=True)
class Action:
name: str
requires: FrozenSet[str]
adds: FrozenSet[str]
cost: int = 1
removes: FrozenSet[str] = frozenset()
# BFS: 对状态做去重，搜索合法动作序列；仅在单位动作成本下保证最少步数。
# 执行循环: 观察当前状态 -> 搜索计划 -> 取下一步 -> 权限校验
# -> 检查前置条件 -> 执行动作 -> 更新状态 -> 必要时重新规划。实验中的 search/read/draft/verify/publish 都是模拟的状态变更，不访问真实网页、不生成真实报告，也不调用 LLM。这样可以隔离测试规划与执行契约本身。
10.2 运行方式与本地结果
python3 A9-Agent-Planning-and-Reasoning-v1.1-demo.py也可从站点直接下载上述配套文件后运行。
本次已在本地实际执行，输出：
A9 planning lab: 7 checks passed
Replanning trace: search -> read -> draft -> OBSERVATION:evidence_invalidated -> read -> draft -> verify七项断言覆盖：正常规划顺序；未审批时发布不可达；搜索扩展预算限制；证据失效后的重新规划；未授权动作被拒；审批条件满足后的发布；执行步数预算停止。测试结果证明此确定性模拟器中的合同与状态逻辑符合断言，不证明开放任务中的 LLM 规划正确率或真实工具可靠性。
10.3 实验解释
第一次 draft 后，模拟环境将 evidence 和 draft 标记为失效；运行时并不继续执行旧计划中的 verify，而是重新从当前状态搜索。由于 sources 仍有效，第二次计划从 read 恢复，随后再次 draft、verify。这展示了重规划的核心不变量：下一步行动必须基于更新后的状态，而非仅基于最初生成的计划。
10.4 该实验尚未覆盖什么
它没有真实工具副作用、异步并发、网络故障、持久化恢复、自然语言目标解析、概率观测、语义验证和模型规划。生产实现需要引入独立任务存储、事件日志、授权服务、工具网关、可观测性和针对真实任务的评测集。代码中的 BFS 不应直接用于大规模开放世界规划。
11 · 研究助理案例：完整决策链
任务：“比较两个框架的持久化执行机制，形成有来源的技术简报。”首先由模型或人工规则提取任务契约：比较对象、关键维度、来源要求、报告格式、截止时间。然后构建任务图：查找各自官方资料 → 读取关键段落 → 提取可追溯证据 → 按维度比较 → 生成初稿 → 验证引用与结论。
如果读取到某框架只保证“恢复编排状态”，而不保证外部 API 调用恰好执行一次，系统需要把“exactly-once”相关断言降级为待核验，并新增“幂等与副作用语义”检索节点。这里的重规划不是换一种写作措辞，而是研究目标的证据依赖发生变化。若用户要求直接发布报告，运行时还需检查是否具备发布权限；规划器的“完成研究”与“可以发布”是两个不同状态。
这一案例同时说明 A6 Knowledge 提供证据、A7 Tools 提供外部操作、A8 Skills 提供研究方法、A9 Planning 负责行动组织、A10 Permissions 负责行动边界；Context 与 Memory 决定哪些信息在当前步骤可见并可跨步骤复用。规划能力是协作机制，不是可以脱离其他能力独立保证成功的模块。
12 · 代表性研究与技术路线对照
| 研究/技术 | 主要思想 | 对 A9 的启发 | 需要注意的边界 |
|---|---|---|---|
| STRIPS（Fikes & Nilsson, 1971） | 用动作前置条件与效果描述状态变化 | 可验证动作契约与可达性 | 开放世界难以完整符号化 |
| PDDL（McDermott 等, 1998） | 规划领域与问题的形式化描述 | 分离动作模型与任务实例 | 形式正确不代表现实模型正确 |
| HTN 规划 | 用领域方法递归分解任务 | 可复用专业任务分解 | 方法库覆盖范围有限 |
| ReAct（Yao 等, 2022/2023） | 行动与环境观察交替 | 在线反馈驱动的局部决策 | 不保证全局最优 |
| Plan-and-Solve（Wang 等, 2023） | 先分解再解决问题 | 显式规划有助于结构化任务 | 主要研究推理提示，不能直接等同工具执行框架 |
| Tree of Thoughts（Yao 等, 2023） | 搜索并评估多条候选思路 | 搜索可改善某些复杂问题 | 评价误差与成本可能较高 |
| Reflexion（Shinn 等, 2023） | 利用反馈改进后续尝试 | 反馈可影响下一轮策略 | 不能等同可靠长期学习 |
| LLM+规划器研究 | 模型进行语义转译，规划器做结构搜索 | 语义与可验证搜索互补 | 转译与动作模型误差仍是瓶颈 |
这里比较的是机制，不是跨论文的性能排行榜。不同研究任务、基准和资源预算不同，不能直接据此断言某路线普遍优于其他路线。
13 · 典型失败模式与工程对策
计划幻觉。 模型规划调用不存在的工具或使用错误参数。对策是只允许引用 Tool Registry 中真实存在的工具，并进行结构化校验；错误时反馈实际可用能力，而非无限重试。
错误前置条件。 计划要求在获得证据前写出结论。对策是用可检查的产物依赖和验收条件表达关键约束；不应只凭步骤名称判断完成。
状态漂移。 计划生成后文件被修改或外部资源失效。对策是执行前核对版本、重要动作前重新观测、必要时局部重规划。
错误自证。 模型自己生成结论，又自己声明已验证。对策是将关键验收委托给独立检查器、外部证据或人工审批，并保留失败证据。
循环与成本失控。 Agent 在“再搜索一次”之间反复徘徊。对策是限制动作数、模型调用数、费用、重复状态及总耗时，并设计明确的终止与升级策略。
不可逆副作用。 计划重试发送消息、付款或发布操作。对策是将计划与执行权限分离，使用幂等键、确认步骤和外部状态核对；不要把“重新规划”当作“回滚”。
规划过度。 对简单任务生成复杂 DAG 或多轮搜索。对策是先建立无需规划的基线，只有在质量、效率或风险控制收益明确时增加规划层。
14 · 测试与评估设计
评估应至少区分四层：
- 计划结构正确性：节点有效率、依赖无环率、前置条件满足率、不可达目标识别率。
- 执行一致性：非法动作拦截率、过期计划检测率、状态更新准确率、重规划恢复率。
- 任务结果：目标达成率、验收通过率、证据支持率、人工修正率。
- 资源与安全：调用成本、延迟、预算超限率、未经授权副作用发生率。
建议建立对照实验：固定工作流、LLM 逐步决策、先规划后执行、规划加反馈重规划。控制任务集、模型、工具、预算和评估标准，报告样本量与置信区间；按任务复杂度和环境变化程度分层。对于失败，需要记录错误发生在目标解析、状态观测、动作模型、计划搜索、工具执行还是结果验收，否则“规划失败率”没有诊断价值。
15 · 与相邻专题及 Agent System 的边界
A2 Model 研究模型能力及调用；A3 Instructions 规定行为要求；A4 Context 组织当前可用信息；A5 Memory 提供跨任务信息；A6 Knowledge 负责外部证据；A7 Tools 负责可调用行动接口；A8 Skills 提供可复用任务方法；A9 研究如何依据目标和状态形成、选择及修订行动方案；A10 Permissions & Constraints 则强制约束可执行动作。
Agent System 进一步研究执行引擎、任务队列、持久化、并发、检查点、故障恢复与系统级观测。A9 可以定义“需要重规划”，但具体的任务唤醒、状态事务、并发调度和副作用恢复通常属于运行基础设施。一个 Agent 可以在单进程中实现最小规划循环，无需因此部署独立规划服务或平台。
下一篇 A10 · Permissions & Constraints 将深入研究授权、预算、审批与行为约束的强制执行模型。
16 · 核心结论
规划的本质是在目标、当前状态、可行动作与约束之间建立可检验的行动关系。推理为规划提供语义理解和候选判断，搜索算法可在明确的动作模型中检查可达性或优化成本，运行时将授权后的动作落实为真实执行，反馈再推动状态更新与重规划。
没有任何单一机制能够保证开放世界 Agent 的规划可靠性。自然语言计划缺少可执行保证，符号计划依赖正确的环境模型，搜索增加计算成本，反馈重规划又会引入状态一致性与副作用问题。工程设计应依据任务结构选择最低必要复杂度，并以实际执行轨迹、验收结果和风险指标评估成效。
17 · 参考研究与进一步阅读
以下是可检索的经典论文与标准资料。论文的核心机制以已知研究内容概述；本次未逐篇在线重新核验原文、最新修订或相关框架的现行 SDK 接口，因此不将它们标记为“研究当日已核验”。
- Fikes, R. E., & Nilsson, N. J. (1971). STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving. Artificial Intelligence.
- McDermott, D., et al. (1998). PDDL — The Planning Domain Definition Language. AIPS Planning Competition technical report.
- Ghallab, M., Nau, D., & Traverso, P. (2004). Automated Planning: Theory and Practice. Morgan Kaufmann.
- Yao, S., et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR.
- Wang, L., et al. (2023). Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models. ACL.
- Yao, S., et al. (2023). Tree of Thoughts: Deliberate Problem Solving with Large Language Models. NeurIPS.
- Shinn, N., et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. NeurIPS.
- Nau, D., et al. (2003). SHOP2: An HTN Planning System. Journal of Artificial Intelligence Research.
关联研究：A2 Model；A4 Context；A6 Knowledge；A7 Tools；A8 Skills；A10 Permissions & Constraints；Fundamentals 04 Execution Mechanism、06 Agent Design、07 Agent Lifecycle；Agent System 中的 Agent Engine 与 State Management。
研究声明
- 研究基准日期：2026 年 10 月 28 日。
- 在线核验：本次未开展新的网页检索；参考文献为可检索研究线索，论文细节及最新版本需要后续原文复核。
- 工程验证：已在本地使用 Python 3 执行配套
A9-Agent-Planning-and-Reasoning-v1.1-demo.py，七项断言通过（输出A9 planning lab: 7 checks passed）。验证范围仅限确定性规划与模拟状态转换。 - 未验证范围：真实 LLM 的任务分解与规划能力、实际工具成功率、外部副作用、并发、持久化、SDK 兼容性、真实任务性能。
- 研究性质：本文中的统一数据契约、分层架构和测试建议属于面向工程的综合设计建议，不应误认为任何特定论文或框架的正式标准。