context-infra 检查与复盘infra.guiming.net · 全内容自包含呈现 · 生成于 2026-07-21 16:28 UTC

agentic_task_realization_20260521_manual

Z3 全文↑ Z2 条目

方法论库 · 引用级 · none

← 返回方法论库索引 · 返回方法论区

本页是 <code>contexts/methodology/agentic_task_realization_20260521_manual.md</code> 的逐字投影（仅隐私清洗，零改写）。

时点提示：本页是仓内文件 contexts/methodology/agentic_task_realization_20260521_manual.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。

报告元数据（frontmatter）
name: agentic_task_realization_20260521_manual
description: Agentic Task 实现闭环
domain: infra
consumption:
  surface: none
  trigger: ""
  consumer: orchestrator
status: library
promoted_to: null

Agentic Task Realization：从大模型到任务完成的统一定义

Date: 2026-05-21
Author: Codex
Scope: 定性定义 LLM/Agent 如何把一个开放式任务实现为可验证完成事实

Version note:

0. 结论摘要

前两份报告分别回答了两个问题：

  1. LLM 是什么：LLM 是上下文条件化、注意力有界、近似无状态、不能自证完成的概率候选生成系统；可靠性来自外部 harness、状态、工具、验证与人类判断。
  2. Agentic Task 是什么：Agentic Task 是由人类意图触发、在无限潜在上下文中以有限预算选择足够信息和操作路径，把当前状态转化为可验收目标状态的开放式控制问题。

本报告补上第三层：从 Agent 到任务完成的过程本体。

另一个关键补充是训练视角：现代 LLM 主要通过预训练、指令微调、偏好优化、RLHF/RLAIF、工具或轨迹示例来塑造输出策略；这些训练能显著改善指令跟随和候选生成，但并不会自动把真实任务完成所需的本地状态、责任边界、验收标准、长期记忆、组织流程和外部世界后果写进模型权重。因此 ATR 也是对 训练-任务缺口 的补偿结构。

建议命名：

Agentic Task Realization（代理任务实现闭环，简称 ATR）

精炼定义：

Agentic Task Realization 是一种外部可审计的闭环控制系统：它在 LLM 只能生成概率候选、任务上下文原则上无限、资源有限的前提下，将人类意图压缩为可验证任务合约，选择足够上下文与方法，编排模型、工具、sub-agent、外部状态和验证器，通过生成、执行、观测、修正、验证、恢复的循环，把初始状态推进到满足验收阈值的目标状态；若无法达成，则以明确残余边界、证据和下一步控制点收束。

更短的定义：

任务实现闭环是在有限资源下，把无限上下文中的人类意图，通过 Agent/harness 转换为可验证状态改变的控制过程。

1. 三层对象：LLM、Agentic Task、Agentic Task Realization

1.1 LLM

LLM 不是完成任务的主体，而是一个上下文条件化的概率候选生成器。它能生成文本、判断、代码、计划和行动候选，但它本身没有稳定的外部状态、不能完整观测世界、不能保证事实正确，也不能自证任务完成。

LLM 的核心性质：

1.2 Agent

Agent 是 LLM 加上上下文、工具、权限、外部状态、反馈循环和治理规则之后形成的受管理执行单元。

Agent 的能力来自组合，而不是来自 LLM 本身：

1.3 Agentic Task

Agentic Task 是面向 Agent 的任务合约，而不是一句自然语言请求。

它可被定义为：

Agentic Task 是一个由人类意图触发、在无限潜在上下文中以有限预算选择足够信息和操作路径，把当前状态转化为可验收目标状态的开放式控制问题。

可形式化为：

T = <I, S0, G_eta, C_infty, rho, A, M, B, V, F, R>

其中：

1.4 Agentic Task Realization

Agentic Task Realization 是任务合约被执行、验证、留痕后形成完成事实的过程系统。

它不是 prompt，不是 plan，也不是 agent 的一次回答。它是一个 operational protocol：从任务合约开始，到证据支持的完成或边界清晰的未完成为止。

形式化表达：

ATR(T) = <T_c, C*, B, P, A_topo, X, L, V, O, Rec, H>

其中：

停止条件：

Done(T) := V(S_n, G_eta, E_n) = pass ∧ residuals_declared ∧ state_persisted

也就是说，完成不是模型说“完成了”，而是目标状态、验收证据、残余说明和状态留痕同时成立。

2. Source Manifest

本报告综合了以下本地材料和 sub-agent 审查结果。

Coverage boundary: 本报告属于 synthesis-scale review，使用了本地已整理的报告、skill draft、harness guide 和多 sub-agent 审查；它不声称完成 full Large Context coverage proof。严格的 full coverage proof 还需要独立产出 source_manifest.tsv、token_budget.json、chunk_ledger.tsv、first_layer/、coverage_audit.md、second_layer/ 和 residual_ledger.md 等完整工件链。

2.1 前置定义报告

2.2 Large Context / workflow skills

2.3 LLM Harness KB / harness guides

2.4 书籍与 skill draft

2.5 Workspace axioms

2.6 Sub-agent inputs

Four independent sub-agents reviewed:

Their overlap was intentional: the same definition was challenged from workflow, theory, safety, and user-operating-model perspectives.

2.7 External training references

Used only to characterize the mainstream training/task gap, not to claim knowledge of any private model's exact training recipe:

2.8 Coverage residuals

This report is a synthesis over local book overviews, skill drafts, KB reports, and harness guides. It does not claim to have reread the full original books end to end. For a formal publishable theory, the next pass should sample the original chapters around:

For current workspace design purposes, the local distillations are sufficient because the goal is not textual exegesis, but a task-system definition.

3. 理论基底：为什么它必须是闭环控制系统

3.1 Simon：任务是 inner/outer environment 的适配

Agent 的内部能力与任务环境并不天然匹配。任务实现需要把外部目标状态翻译为内部可执行过程，并在有限资源下 satisficing，而不是追求无限优化。

对 ATR 的含义：

3.2 Newell & Simon：方法依赖问题空间

一个任务能否被解决，取决于 states、operators、tests 是否被构造成可操作问题空间。只给目标、不定义可用 operator 和 test，会让 Agent 只能生成看似合理的叙述。

对 ATR 的含义：

3.3 Ashby / Beer：有限 variety 必须工程化

任务环境的复杂性可能超过单个 Agent 的调控容量。控制系统必须通过压缩、放大、路由、分解和升级来管理 variety。

对 ATR 的含义：

3.4 Pólya：启发式与验证必须分层

理解问题、制定计划、执行计划、回看结果是良结构任务的基础框架。但启发式只负责产生候选路径，证明、测试和验收负责确认结果。

对 ATR 的含义：

3.5 Lakatos：失败不是噪声，而是边界发现

反例、失败、异常输出揭示隐藏前提。局部反例可能修补步骤，全局反例可能要求改定义、改目标或改 proof architecture。

对 ATR 的含义：

3.6 Meadows：任务推进会受反馈、延迟和结构支配

复杂任务不是线性步骤表。它会出现反馈延迟、局部优化、目标漂移、指标替代和结构性复发。

对 ATR 的含义：

3.7 Weick / Klein：高不确定环境需要弱信号和意图优先

真实任务经常不是良结构题。专家会在不完整信息下识别模式、模拟候选行动、执行并快速修正；高可靠组织会避免过早简化，尊重相关 expertise。

对 ATR 的含义：

3.8 训练-任务缺口：训练出来的是输出策略，不是完成制度

现代 LLM 的主流训练可以粗略理解为几层叠加：

  1. 预训练：在大规模语料上学习 next-token prediction，获得语言、代码、事实片段、模式和世界先验。
  2. 指令微调 / SFT：用人工示范或任务样本训练模型更像一个会回答指令的助手。
  3. 偏好优化 / RLHF / RLAIF：用人类或 AI 偏好训练 reward model，再优化模型输出更符合偏好。
  4. 工具使用或 agent 轨迹训练：让模型学习何时调用 API、如何格式化 action、如何利用 observation 更新输出。

这些训练解决的是“在一个给定 prompt 与可见上下文下，输出什么更可能被认为好”的问题。它们不等价于训练了一个能在真实组织和真实文件系统中可靠完成任务的制度。

因此需要定义：

Training-Task Gap（训练-任务缺口，TTG）是指真实任务完成所必需、但没有被模型训练分布充分覆盖，或无法稳定写入模型权重，必须在部署时由 context、harness、工具、外部状态、验证器和人类 gate 提供的要素集合。

换句话说，ATR 不是简单补 prompt，而是在部署层补齐 TTG。

真实任务中常见的 TTG 包括：

缺口为什么训练中通常没有充分学到ATR 如何补
本地真实状态私有仓库、当前文件、未提交 diff、外部系统状态不在训练数据中，且持续变化读取文件、git diff、日志、数据库、state ledger
完成标准训练偏好通常评价回答质量，不直接评价真实世界状态是否改变Task Contract、acceptance tests、Stop-time validation
责任与权限边界模型不会天然知道当前用户、组织、项目的不可逆操作边界human gate、权限规则、forbidden actions
Source authority 与新鲜度预训练知识静态且混合多来源；模型不知道当前任务的权威源source manifest、web/local retrieval、citation、freshness check
长期状态与恢复单次 forward 不提供可靠 mutable memoryscratchpad、handoff、checkpoint、transcript、pending queue
成本与预算训练目标很少包含真实 token、时间、钱、人类注意力和机会成本budget model、max turns、cost monitor、scope gate
组织 tacit knowledge团队习惯、命名约定、历史事故、隐含禁区常不在公开语料repo rules、AGENTS.md、skills、memory docs、user axioms
外部行动后果训练多是文本评价，不承担文件删除、发布、付费调用、用户影响tool poka-yoke、dry run、rollback、approval
多 Agent 合并协议训练样本很少覆盖真实并行工作、冲突合并、责任归属task cards、write ownership、coverage audit、integration review
失败分类与 residual偏好训练容易奖励流畅闭合，而不是清晰承认边界residual ledger、blocked/bounded_incomplete status
反例和独立否证模型会生成自洽叙事，但不天然维护反证流程critic、counterexample search、external verifier
价值判断偏好数据代表特定 labeler/政策，不等于当前用户或组织价值user gate、policy context、explicit tradeoff decision

TTG 解释了为什么“更强模型”仍然需要 harness：

这也改变 Agent-to-Agent 任务设计：

  1. 不要假设 sub-agent 知道“什么不能改”。必须在派发 prompt 中写明 write scope、事实锚点、禁止事项。
  2. 不要假设 reviewer 会自动验证真实状态。必须给它原始任务、产物、diff、日志和验收标准。
  3. 不要假设 domain specialist 会自动发现方法论缺口。需要 Method Controller 明确问题空间和反例机制。
  4. 不要假设多 Agent 会自然合并。需要 ownership、merge protocol、coverage ledger 和 integration review。
  5. 不要假设模型会自动停在合理边界。需要预算阈值、completion schema 和 residual status。

因此，ATR 的更深层定义可以补上一句：

ATR 是把模型训练没有内化、也不应完全内化的真实任务制度外置化、显式化、可审计化的过程。

4. 代理任务实现闭环的必要环节

下面是从 Agent 到完成任务的必要环节。不同任务可裁剪强度，但不能在概念上删除这些层。

4.1 Intake：意图接收与锚定

目标：

产物：

核心原则：

任务开始不是“立刻回答”，而是把模糊意图压缩成可执行、可验收、可追责的任务入口。

4.2 Task Contract：任务合约

任务合约定义 Agent 到底要改变什么状态。

必须包含：

没有任务合约，Agent 只能根据 prompt 的局部语义生成高概率输出，而不是执行可控任务。

4.3 State & Problem Space Modeling：状态和问题空间建模

目标：

问题空间至少回答：

4.4 Context Frontier：上下文边界选择

面对无限 context，不能追求全量，只能追求足够控制任务的相关上下文。

核心对象：

判断标准：

4.5 Budget & Variety Routing：预算与调控容量判断

预算不是附属参数，而是任务性质的一部分。

预算维度：

调控容量问题：

当前 Agent/harness 的 variety 是否足以控制任务环境的 variety？

如果不足，必须做至少一种动作：

4.6 Methodology Selection：方法论选择

方法不是“怎么做”的装饰，而是任务从目标状态到执行过程的转换规则。

典型方法路由：

4.7 Decomposition & Agent Topology：任务分解与 Agent 编排

分解的目的不是把任务切碎，而是让每个子任务在当前能力边界内可完成、可验证、可合并。

有效子任务必须有：

Sub-agent 的典型角色：

多 Agent 的价值来自上下文隔离、并行覆盖和交叉验证，不来自角色拟人化。

4.8 Prompt / Context Injection：引导式上下文注入

由于 LLM 输出高度依赖当前上下文，prompt 的作用不是“命令模型聪明起来”，而是构造一个能让高概率输出接近目标的局部世界。

高质量 prompt 应包含：

关键规则必须进入 attention 的 primacy 区或必要 recap，而不是只存在于仓库某处。

4.9 External State：外部状态与长期记忆

LLM 不能承担长期 mutable state。ATR 必须把关键状态外置。

外部状态包括：

原则：

对复杂任务，未写入外部状态的关键认知应视为不稳定状态。

4.10 Execution Loop：生成、执行、观测、更新

执行循环的基本形态：

  1. 根据任务合约和当前外部状态选择下一步。
  2. LLM 生成候选行动或候选解释。
  3. 工具或 Agent 执行行动。
  4. 观察外部结果。
  5. 写入 evidence/log。
  6. 用 verifier 或 critic 判断是否偏离。
  7. 更新任务状态、预算和下一步。

这是一种 generator-test loop。生成负责提出候选，测试负责收束不确定性。

4.11 Runtime Governance：运行时治理

Stop-time validation 会晚于错误发生，所以复杂任务必须在执行中治理。

Runtime governance 需要监控：

治理动作：

4.12 Verification & Completion Validation：验证与完成判定

验证分两层：

  1. Step verifier：每一步是否产生预期局部效果。
  2. Stop-time completion validation：最终是否满足原始任务合约。

完成验证不能由执行 Agent 单独完成。它应尽量独立看：

完成判定的四个问题：

4.13 Observability & Recovery：观测与恢复

Observability 是被动记录事实；governance 是主动干预。二者应分开。

Observability 记录：

Recovery 要求：

4.14 Synthesis, Closure & Learning：综合、收束与学习

收束不是写一个漂亮总结，而是把任务状态交付给用户和长期记忆。

闭合产物：

闭合状态有三种：

5. Large Context 下的 ATR 工程化流程

当任务涉及大量资料、长代码库、多本书、多轮调研或复杂历史 context 时，应使用 Large Context pipeline。

推荐工件链：

  1. source_manifest.tsv
  2. token_budget.json
  3. chunk_ledger.tsv
  4. prompts/
  5. first_layer/*.md
  6. coverage_audit.md
  7. second_layer/*.md
  8. confirmation_plan.md
  9. claim_ledger.md
  10. decision_ledger.md
  11. verification_log.md
  12. residual_ledger.md
  13. synthesis.md

5.1 第一层：原始资料覆盖

第一层 sub-agent 应直接读原始资料或 source chunk，不读上游摘要。

输出：

5.2 第二层：压缩判断复杂度

第二层不应随意扩大材料范围，而是做聚合判断：

5.3 第三层：独立 critic

Critic 不继承 executor 的成功叙事。它主要检查：

5.4 第四层：version / memory closure

如果产物影响规则、skill、设计文档、版本承诺或长期操作方式，最后必须检查：

6. “哲学家模型 + 科学家模型”的更精确定义

用户提出的类比是有价值的，但需要避免人格化。更准确的系统角色是：

6.1 Method Controller

相当于“哲学家”的非人格化版本。

职责：

它的能力不是领域知识最强，而是控制 problem framing、method routing 和 epistemic discipline。

6.2 Domain Specialist

相当于“科学家”的非人格化版本。

职责：

它的风险是被既有表示限制，可能在默认范式内局部最优。

6.3 Critic / Verifier

职责：

6.4 Operator / Tool Executor

职责：

6.5 Memory / Archivist

职责：

6.6 组合原则

突破性工作不是“哲学家告诉科学家答案”。更严谨的说法是：

Method Controller 提供问题表征、方法选择、反例机制和验收纪律；Domain Specialist 提供专业内容和局部可行性；Critic 提供独立否证；Tool Executor 改变外部状态；Memory 保存认知资产。新的理论或高质量方案来自这些角色之间的受控反馈，而不是来自某一个模型的单次灵感。

7. Bad Behavior 到控制环节的映射

Bad behavior表现ATR 控制环节
目标锚定失败回答了相邻问题，忘记原始 askIntake, Task Contract, Context Injection
Source 锚定失败使用未授权来源或过期知识Source Manifest, Context Frontier, Verification
Overclaim产物没通过检查却声称完成Stop-time Validation, Independent Critic
Proxy success有文件、有摘要、有测试输出，但不满足任务真实目标Task Contract, Semantic Verifier
Silent simplification隐式缩小任务或省略困难部分Requirements Ledger, Critic, Residual Ledger
Scope expansion越做越大，消耗预算Budget Model, Runtime Governance
Tool misuse错用命令、误读工具输出Tool Poka-yoke, Step Verifier
Context decay长任务中忘记关键约束Recap, External State, Primacy Injection
Self-verification生成者自己证明自己完成Independent Critic, Deterministic Tests
Soft-exit masquerading completion达到迭代上限却写成完成Recovery Status, Completion Schema
Workspace state invisibility不知道文件实际变了什么Diff, Git status, Evidence Log
Unbounded retry反复尝试但没有新信息Hypothesis Tree, Budget Gate, Human Gate

8. Prompt 设计原则：让概率模型进入正确局部世界

LLM 会倾向输出当前 prompt 下最相关、最自然、最高概率的候选。因此 prompt 的关键不是“更强命令”，而是控制概率场。

8.1 Prompt 必须提供的上下文

一个复杂 Agentic Task prompt 应至少包含：

8.2 Prompt 的本质

Prompt 是任务合约、上下文选择、方法论和治理规则的注入载体。

低质量 prompt：

“帮我研究一下 X。”

高质量 prompt：

“在给定 source manifest 和预算下，按 claim extraction -> coverage audit -> critic -> synthesis 的流程，回答 X 的定义问题；每个结论必须有来源或标记为推断；最终输出 definition、properties、failure modes、residuals。”

8.3 对“前瞻性”的解释

前瞻性 prompt 不是预测所有细节，而是提前定义：

9. 资源有限性的任务设计规则

9.1 预算决定任务形态

同一意图在不同预算下不是同一个任务。

例如“分析某个理论”：

因此任务合约必须显式说出预算，或由 Agent 估计预算并声明任务强度。

9.2 预算分配优先级

复杂任务应优先花预算在：

  1. 明确验收标准。
  2. 找到高影响上下文。
  3. 建立问题空间。
  4. 做最小可验证行动。
  5. 独立审查。
  6. 保存 residual 和 evidence。

不应优先花预算在：

9.3 任务收束策略

当预算不足时，不应假装完成，而应收束为：

10. 统一过程模型

推荐把 ATR 视为 14 个环节的闭环，而不是线性 checklist：

  1. Intake：接收并锚定用户意图。
  2. Task Contract：形成任务合约。
  3. State Modeling：建模当前状态、目标状态、可观测状态。
  4. Context Frontier：选择有限上下文并记录 residual。
  5. Budget Routing：判断资源、风险和调控容量。
  6. Method Selection：选择问题求解方法。
  7. Decomposition：拆成可验证子任务。
  8. Agent/Tool Topology：编排模型、工具、sub-agent、人类 gate。
  9. Context Injection：把关键规则和资料放进 attention。
  10. Execution Loop：生成、执行、观测、更新。
  11. Runtime Governance：监控漂移、风险和错误。
  12. Verification：步骤验证与最终完成判定。
  13. Observability/Recovery：记录状态、支持恢复、避免伪完成。
  14. Closure/Learning：交付、残余、长期记忆、版本判断。

ASCII flow:

Human Intent
  -> Intake
  -> Task Contract
  -> State / Problem Space
  -> Context Frontier + Budget
  -> Method + Agent Topology
  -> Prompt / Context Injection
  -> Generate / Act / Observe / Update
  -> Runtime Governance
  -> Verification
  -> Completion or Residual Closure
  -> Memory / Version / Recovery State

核心循环：

while not Done and budget remains:
    choose next action from task contract, state, method, evidence
    generate candidate with LLM
    execute through tool/agent
    observe result
    write evidence and state
    verify local effect
    detect drift/risk
    update plan, context frontier, residuals

if Done:
    close with evidence
else:
    close as bounded_incomplete or blocked

11. 最终定义版本

11.1 LLM

LLM 是一个上下文条件化、注意力有界、近似无状态且不能自证完成的概率候选生成系统。它能产生语言、判断、代码、计划和行动候选，但可靠任务完成必须依赖外部状态、工具、验证、治理和人类责任边界。

11.2 Agent

Agent 是 LLM 与上下文、工具、权限、外部状态、反馈循环和治理规则耦合后形成的受管理执行单元。它不是自主责任主体，而是可被任务合约约束、可被工具放大、可被验证器校正的执行系统组件。

11.3 Agentic Task

Agentic Task 是由人类意图触发、在无限潜在上下文中以有限预算选择足够信息和操作路径，把当前状态转化为可验收目标状态的开放式控制问题。

11.4 Agentic Task Realization

Agentic Task Realization（代理任务实现闭环）是在 LLM 概率性、上下文无限性和资源有限性的约束下，通过任务合约、上下文选择、方法路由、Agent/工具编排、外部状态、运行时治理、独立验证、观测恢复和人类 gate，将开放式任务转化为可验证完成事实或边界清晰未完成状态的闭环控制系统。

训练视角下的补充定义：

ATR 也是对训练-任务缺口的部署层补偿：它把模型训练没有稳定学到、或不可能提前学到的本地状态、完成标准、权限边界、组织知识、验证制度、成本约束和恢复机制，转化为显式 context、工具协议、外部状态和审查流程。

11.5 完成事实

完成事实不是 Agent 的完成声明，而是目标状态改变、验收证据、独立检查、残余风险声明和外部状态留痕共同成立。

12. 实践模板

任何复杂 Agentic Task 可以先填以下模板。

Task Contract
- Intent:
- Current state:
- Target state / acceptance threshold:
- Non-goals:
- Constraints:
- Authority / forbidden actions:
- Risk level:
- Required artifacts:

Context Frontier
- Must read:
- Should read if budget allows:
- Do not use:
- Unknowns:
- Residuals accepted for this pass:

Budget
- Time:
- Token/context:
- Tool calls:
- Sub-agents:
- Human gates:
- Verification strength:

Method
- Problem type:
- Chosen methodology:
- Why this methodology fits:
- Failure modes to watch:

Agent Topology
- Controller:
- Extractors:
- Domain specialists:
- Critic:
- Verifier:
- Memory/log owner:

Execution
- Step plan:
- Evidence expected per step:
- Drift signals:
- Recovery points:

Closure
- Done criteria:
- Validation method:
- Residual ledger:
- Long-term memory/update:
- Version decision:

13. Residual Ledger

Unresolved or intentionally bounded issues:

  1. Full original-book reread was not performed. The synthesis depends on local book overviews and skill drafts.
  2. The ATR definition is currently a conceptual framework, not yet a runnable workspace skill.
  3. The exact threshold for when a task requires full Large Context pipeline versus lightweight source review should be operationalized in a future rule or skill.
  4. The relation between workflow_controller_loop and workflow_long_context_scale_up could be formalized into a single controller protocol.
  5. A future implementation should add standard artifacts: task_contract.md, context_frontier.md, claim_ledger.md, decision_ledger.md, verification_log.md, and residual_ledger.md.

14. 下一步建议

如果要从调研产物晋升为 workspace practice：

  1. 创建一个新 skill 或 rule，建议命名为 workflow_agentic_task_realization。
  2. 以本报告作为概念源。
  3. 在 skill 中加入轻量级任务规模决策树。
  4. 定义标准文件模板。
  5. 更新 rules/skills/INDEX.md。
  6. 在 tag 或声明 stable version 前应用 workflow_version_evolution.md。

15. 执行面选择决策树

不同任务不应使用同一强度的 ATR。推荐先用以下轻量决策树选择执行面。

15.1 Inline task

适用条件：

最低要求：

15.2 Controller loop

适用条件：

最低要求：

15.3 Full Large Context ATR pipeline

适用条件：

最低要求：

15.4 Recoverable overlay / scheduled loop

适用条件：

最低要求：

16. Sub-agent 关键结论索引

本次综合使用了五个 sub-agent 结果。关键结论如下：

  1. Large Context / skill orchestration reviewer：
  1. Book-theory extraction reviewer：
  1. LLM Harness / bad behavior reviewer：
  1. User axioms / management alignment reviewer：
  1. Coverage / version reviewer：

17. 三定义框架的充分性判断

用户提出的三项定义是：

  1. Agent 是什么。
  2. 任务是什么。
  3. Agent 与任务之间的 Gap 是什么。

判断：

这三项适合作为一级本体，足以覆盖“Agent 完成真实世界任务”这个研究对象的核心结构；但第三项必须定义为广义 Agent-Task Gap，而不能只定义为 Training-Task Gap。

原因是：

因此，三定义框架可写成：

Agent + Task + Agent-Task Gap
  -> Realization Protocol
  -> Completion Fact

其中前三者是一阶定义；后两者是派生定义。也就是说，额外概念需要定义，但不必升级为同等一级对象。

17.1 一阶定义 1：Agent

建议定义：

Agent 是由 LLM、上下文、工具、权限、外部状态接口、反馈循环和治理规则组成的受管理执行单元。它的核心能力是根据当前可见上下文生成候选判断与候选行动，并通过工具改变外部状态；它的核心边界是概率性、注意力有界、局部可见、训练分布受限、不能自证完成、不能独立承担责任。

Agent 定义中应包含的子项：

归类原则：

凡是描述“执行者本身能做什么、看见什么、如何被训练、如何行动、不能保证什么”的内容，都归入 Agent 定义。

17.2 一阶定义 2：Task

建议定义：

Task 是人类意图在特定环境中的可验收状态转化要求：它从当前状态出发，在有限预算和无限潜在上下文中选择足够相关的信息、方法和行动，将世界、文件、知识状态或决策状态推进到满足验收阈值的目标区域；若无法完成，则必须形成边界清晰的未完成状态。

Task 定义中应包含的子项：

归类原则：

凡是描述“要完成什么、为什么完成、完成到什么程度、受哪些资源和上下文限制”的内容，都归入 Task 定义。

17.3 一阶定义 3：Agent-Task Gap

Training-Task Gap 只是 Agent-Task Gap 的一个子类。更完整的定义应是：

Agent-Task Gap 是某个 Agent 的可见上下文、训练内化能力、工具权限、状态接口、方法能力、验证能力和责任边界，与某个 Task 的目标状态、上下文需求、行动后果、验收标准、风险和资源约束之间的差距。这个差距决定了任务不能仅靠一次模型输出完成，而必须通过 prompt、context、tools、harness、sub-agent、external state、verification、observability、recovery 和 human gate 来补齐。

Agent-Task Gap 至少包含以下子缺口：

子缺口含义归属
Training-Task Gap训练没有覆盖真实任务制度、本地状态和组织规则Agent 与 Task
Context Gap无限潜在上下文无法全部进入 attention，需要选择和压缩Task 与 Context Frontier
State Gap模型内部没有可靠 mutable state，真实状态在外部系统中Agent 与 External State
Method Gap模型会生成答案，但未必选择正确问题空间和方法Agent 与 Methodology
Tool Gap模型知道该做什么，但没有权限、接口或安全协议执行Agent 与 Tooling
Verification Gap生成者不能自证完成，需要外部检查Agent 与 Acceptance
Governance Gap风险、权限、不可逆动作和价值判断不能交给模型自行决定Human Gate
Coordination Gap多 Agent 并行会产生冲突、遗漏、重复和合并问题Agent Topology
Memory Gap长任务中的关键认知会衰减或丢失External Memory
Budget Gap模型倾向继续生成，但任务资源有限Budget Control

归类原则：

凡是描述“为什么当前 Agent 和当前 Task 之间不能直接闭合、需要什么桥接结构”的内容，都归入 Agent-Task Gap。

17.4 二级派生定义 A：Realization Protocol

三条一阶定义描述了对象和差距，但还需要一个派生定义描述如何闭合差距。

建议定义：

Realization Protocol 是为闭合 Agent-Task Gap 而设计的执行协议：它把 Task 转换为任务合约，选择必要上下文和方法，配置 Agent/工具/sub-agent 拓扑，外置状态与证据，在运行中治理漂移与风险，并用独立验证决定完成或边界清晰地停止。

它包括：

地位：

Realization Protocol 不必作为第四个一级对象，因为它是 Agent-Task Gap 的闭合机制。

17.5 二级派生定义 B：Completion Fact

还必须定义什么算完成，否则无法区分真实完成和完成声明。

建议定义：

Completion Fact 是 Task 的目标状态改变、验收证据、独立检查、残余风险声明和外部状态留痕共同成立的事实状态。它不是 Agent 的文本声明，也不是某个中间 artifact 的存在。

Completion Fact 的判定式：

Done(T) :=
  target_state_changed
  AND acceptance_evidence_passed
  AND independent_or_deterministic_check_performed
  AND residuals_declared
  AND state_persisted

地位：

Completion Fact 也不必作为第四个一级对象，因为它是 Task 的验收谓词，也是 Realization Protocol 的停止条件。

17.6 是否还需要额外一级定义？

当前不建议再增加新的一级定义。

原因：

因此最稳的定义架构是：

一级本体：
1. Agent
2. Task
3. Agent-Task Gap

二级派生：
4. Realization Protocol
5. Completion Fact

17.7 最终判断

Agent、Task、Agent-Task Gap 三条定义是合适的，而且是最小的一级定义集合。它们分别覆盖执行者、被完成对象、二者之间的不可直接闭合性。为了让这套定义可执行，必须再附带两个派生定义：Realization Protocol 说明如何闭合 Gap，Completion Fact 说明何时真的完成。

用一句话概括：

Agent 完成任务的问题，本质上是：给定一个能力有限、训练分布有限、上下文可见性有限的 Agent，面对一个上下文无限、资源有限、验收依赖真实状态改变的 Task，如何识别并闭合 Agent-Task Gap，直到形成可验证的 Completion Fact。

← 返回方法论库索引 · 返回方法论区