agentic_task_ontology_20260521_manual

Z3 全文↑ Z2 条目

方法论库 · 引用级 · none

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

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

报告元数据（frontmatter）

name: agentic_task_ontology_20260521_manual
description: Agentic Task 本体
domain: infra
consumption:
  surface: none
  trigger: ""
  consumer: orchestrator
status: library
promoted_to: null

Agentic Task Ontology：大模型框架下任务的定义与定性

Date: 2026-05-21
Mode: manual synthesis with deep-research evidence discipline
Status: v0.1 research note
Version note: 本文件是新增 Y 级调研产物；建议在载体 commit 后使用下一可用编号打 0.Y-research-agentic-task-ontology。本轮未执行 git tag，因为文件尚未 commit，且用户未要求执行 git 操作。Reason: 下游无需改动；新增 Agentic Task 的定义、性质和任务设计框架，用于后续 agent 编排、prompt 设计和预算决策。

0. 核心定义

本文建议把大模型框架下的任务命名为：

Agentic Task（代理任务）

精炼定义：

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

更完整的定义：

Agentic Task 不是一句待执行的指令，而是一个需要被建模、约束、检索、分解、执行、验证和迭代收敛的状态转换系统。它由目标状态、当前状态、无限上下文、相关性选择机制、可用操作、资源预算、方法论、验证器、风险边界和停止规则共同定义。LLM 在其中承担候选生成、模式匹配、方法调用和局部执行功能；任务可靠性来自外部上下文选择、状态外置、反馈闭环和验收机制。

如果上一轮报告把 LLM 定义为 attention-bounded、近似 stateless、非自证的条件概率 proposal engine，那么本报告对应地把任务定义为：

面向 proposal engine 的有限预算上下文选择与状态转化问题。

1. Source Manifest

source family	主要来源	用途	证据等级
上一轮 LLM 本体报告	`methodology/llm_as_probabilistic_system_20260520_manual.md`	LLM 作为 proposal engine 的前提	本仓库调研结论
陌生任务与书籍调研	`contexts/survey_sessions/books_task_decomposition_unknown_tasks_20260420_deep_research.md`	陌生任务起步、任务拆解、意外处理的书籍地图	既有 deep research
LLM 任务分解	`methodology/llm_task_decomposition_20260414_deep_research.md`, `llm_constraint_capacity_and_task_decomposition_survey_20260414.md`	可验证性、分解粒度、LLM-Modulo、过度分解风险	既有 deep research
人类任务分解史	`methodology/task_decomposition_history_methodologies_survey_20260416.md`	信息隐藏、span of control、mission command、WBS	既有 survey
LLM 能力边界	`methodology/llm_capability_boundary_20260417_deep_research.md`	state writability、attention boundary、context 与 memory 区分	既有 deep research
用户 axioms	`rules/axioms/a01_ask_do_paradigm.md`, `a08_prompt_quality_lever.md`, `t03_context_isolation.md`	ask-do、prompt 质量、context isolation	用户长期认知
书籍 overview	`contexts/library/sciences_of_the_artificial/process/BOOK_OVERVIEW.md`, `human_problem_solving/process/BOOK_OVERVIEW.md`, `introduction_to_cybernetics/process/BOOK_OVERVIEW.md`, `how_to_solve_it/process/BOOK_OVERVIEW.md`, `proofs_and_refutations/process/BOOK_OVERVIEW.md`, `thinking_in_systems/process/BOOK_OVERVIEW.md`, `brain_of_the_firm/process/BOOK_OVERVIEW.md`, `managing_the_unexpected/process/BOOK_OVERVIEW.md`, `sources_of_power/process/BOOK_OVERVIEW.md`	状态转化、问题空间、variety、反馈、反例、可靠性、专家决策	distilled overview

Residuals:

本轮主要综合本仓库既有材料，没有新增外部 web research。
多数书籍使用 BOOK_OVERVIEW.md 和 draft skill，不声称逐页回源。
本文目标是定义任务对象和设计框架，不是给所有任务类型做完整 taxonomy。

2. 任务的本体：它不是指令，而是状态转化

人类说的任务，表面上是一句话：

帮我修这个 bug。
帮我证明这个猜想。
帮我调研这个领域。
帮我写一个方案。

但在 Agent 系统中，这句话只是入口，不是任务本体。任务本体是：

当前状态 S0
  在约束和预算 B 下
  通过上下文选择 C* 与操作序列 A*
  转化为可验收目标状态 G_eta

这与 Simon 的设计定义一致：设计是把现有状态变成偏好的状态。与 Newell/Simon 的问题空间一致：任务要被表示为 states、operators、goal test。与 Ashby 一致：任务是环境 variety 与 regulator variety 的匹配问题。与 LLM 框架一致：模型只能在当前 context 中生成候选，系统必须决定哪些 context 进入模型、哪些操作交给工具、哪些结果算完成。

因此：

任务是意图的工程化形式。

人类意图通常是模糊的，任务对象必须把它转成可操作结构：

要改变什么状态；
当前状态是什么；
哪些上下文可能相关；
哪些上下文值得付费获取；
可以采取哪些行动；
什么方法论负责选择行动；
什么时候停；
如何证明完成。

3. Agentic Task 的形式化定义

一个 Agentic Task 可以表示为：

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

各项含义：

符号	名称	含义
`I`	Intent	人类意图。通常模糊、压缩、带隐含价值判断。
`S0`	Current State	当前世界、代码库、知识状态、文件状态、系统状态。
`G_eta`	Acceptable Goal Region	可验收目标区域。不是单点最优，而是一组满足验收标准的状态。
`C_infty`	Infinite Context Field	理论上无穷的潜在上下文：代码、文档、书籍、历史、网络、工具输出、专家知识。
`rho`	Relevance Policy	相关性选择策略：从无穷上下文中选择有限上下文 `C*`。
`A`	Operators	可用操作：读文件、搜索、写代码、运行测试、调用工具、问人、生成文本。
`M`	Method	方法论：分解、证明、调研、调试、设计、验证、复盘等策略。
`B`	Budget	有限资源：时间、token、金钱、上下文窗口、人类注意力、风险承受度。
`V`	Verifier	验收器：测试、schema、引用核验、人工判断、rubric、反例搜索。
`F`	Feedback Loop	反馈回路：执行后观察结果，更新状态、假设和上下文选择。
`R`	Risk/Stop Rule	风险边界与停止规则：何时继续、何时降级、何时问人、何时停止。

这个 tuple 的关键是 C_infty 与 B 的冲突：

任务永远面对无穷上下文，但执行永远发生在有限预算内。

Agentic Task 的核心工作就是把这个冲突转成可管理的选择过程。

4. 为什么 Context 是无穷的

任何非平凡任务都没有天然边界。一个代码 bug 可能需要：

当前文件；
调用链；
测试；
依赖版本；
用户原始需求；
历史 commit；
issue 讨论；
框架文档；
操作系统行为；
性能指标；
业务目标；
团队约定。

一个研究任务更明显。证明一个猜想可能需要：

概念定义；
已知定理；
反例历史；
相邻领域；
证明技术；
符号系统；
失败路线；
专家 intuition；
相关 conjecture；
文献网络。

所以任务的第一阶段不是执行，而是建模：

从无限上下文字段中建立一个足够好的任务世界模型。

这个模型不需要完整。它需要在预算内足够支持下一步行动。

5. 任务的十个核心性质

性质	含义	对 Agent 设计的影响
意图压缩性	用户输入是高压缩意图，不等于完整任务	intake 阶段必须展开目标、边界和验收
状态转化性	任务目标是改变某个状态，而不是输出一句话	交付物要落到文件、代码、报告、决策或系统状态
上下文无穷性	潜在相关信息无边界	必须有 source manifest 与 relevance policy
资源有限性	时间、token、预算、人类注意力有限	必须预估成本，选择 satisficing 而非最优
部分可观测性	`S0` 通常不完整，任务过程中才逐步显现	需要观察、探针、日志、测试、调研
方法依赖性	不同任务域需要不同 method	先路由任务性质，再选方法，不用统一模板
可验证性差异	有些任务可自动验证，有些只能语义评估	分解粒度必须服从验证器，而不是服从美观结构
递归展开性	执行会产生新信息，改变任务定义	使用 loop，不假设初始 plan 完整
近似可分解性	只有弱耦合、可交接、可验证的部分适合拆	按信息依赖拆，不按角色名拆
风险塑形性	不可逆、高成本、高风险任务需要更强验证	预算不是只算 token，也算错误代价

6. 任务分类的底层轴

面向 Agent 的任务分类不应从行业名开始，而应从能力边界开始。

第一轴：目标状态是否清楚。

清楚：修一个测试、生成一个表、转换一个格式。
半清楚：写设计方案、整理调研、实现 feature。
不清楚：探索研究方向、定义产品、证明猜想、寻找未知根因。

第二轴：验证器是否强。

强验证：测试、类型检查、schema、数学证明、parser。
中验证：引用、rubric、人工审查、对照清单。
弱验证：审美、战略判断、价值判断、开放研究方向。

第三轴：上下文是否可枚举。

可枚举：一个 repo、一个文件夹、一组文献。
半可枚举：仓库 + issue + 文档 + web。
不可枚举：开放研究、市场判断、跨学科理论。

第四轴：状态是否需要跨轮覆写。

不需要：一次性分析或生成。
append-only：读写日志、逐步记录。
需要覆写：计划、方法论、长期记忆、配置、规范。
闭环覆写：状态更新会影响后续状态读取与行动选择。

第五轴：失败成本与可逆性。

低成本可逆：草稿、局部 refactor、探索性分析。
中成本可逆：代码合并、架构方案、内部流程。
高成本或不可逆：公开发布、财务、医疗、安全、删除数据。

这五个轴比任务名更重要。任务名相同，轴的位置不同，Agent 设计完全不同。

7. 任务处理的基本流程

Agentic Task 的基本流程可以概括为：

Intent
  -> Task Contract
  -> Context Frontier
  -> Method Selection
  -> Budget Decision
  -> Decomposition
  -> Execution Loop
  -> Verification
  -> State Update / Closure

7.1 Task Contract

把意图转成最小任务契约：

Objective: 要改变什么状态？
Current state: 当前已知状态是什么？
Deliverable: 交付物是什么？
Acceptance: 什么算完成？
Sources: 哪些 source 权威，哪些只是参考？
Constraints: 最重要的约束是什么？
Non-goals: 明确不做什么？
Budget: 时间/token/风险边界是什么？
Verifier: 用什么证明完成？
Stop rule: 何时停止、升级、问人？

7.2 Context Frontier

面对无穷上下文，先画 frontier：

已知必须读的 source；
可能相关但未确认的 source；
不值得读的 source；
需要工具探测的状态；
需要外部搜索或问人的缺口。

任务失败常常不是模型不会推理，而是 rho 失败：相关性策略没有把正确上下文带进来，或把太多低价值上下文塞进 attention。

7.3 Method Selection

方法论不是装饰，而是任务的 regulator。不同任务需要不同方法：

证明/理论：Pólya 的理解、计划、执行、回顾；Lakatos 的猜想、证明尝试、反例、修补。
调研：Adler 的 syntopical reading；Heuer 的 competing hypotheses；deep-research 的 claim extraction。
代码：Ousterhout/Parnas 的信息隐藏；测试和调试的单变量假设。
未知系统：Ashby 的 black box protocol；Meadows 的 event-pattern-structure；Weick 的 weak signals。
时间紧任务：Klein 的 recognition + mental simulation；commander's intent。

没有方法论的 Agent 是在巨大搜索空间里采样；有方法论的 Agent 是在被约束的空间里搜索。

7.4 Budget Decision

资源预算决定任务策略：

token 不够：先做 source manifest，不读全文。
时间不够：先找高互信息 source，不做全覆盖。
验证成本高：先做小样本 probe。
错误成本高：先提高 verifier 强度。
上下文耦合强：少分解，多用单一高上下文 agent。
子任务弱耦合：并行分解，保留 shared scratchpad。

这里的关键是 satisficing：在有限预算内找到满足验收标准的状态，而不是追求理论最优。

7.5 Decomposition

任务分解的判据不是“能不能拆成多个列表项”，而是：

子任务是否能独立获得必要上下文；
子任务输出是否可验证；
子任务之间的依赖是否明确；
聚合是否比单 agent 处理更可靠；
协调成本是否低于收益。

这继承了 Simon 的 near-decomposability、Parnas 的信息隐藏、Brooks 的沟通开销、用户的 context isolation 公理。

7.6 Execution Loop

执行不是线性推进，而是：

generate candidate
  -> act / test / observe
  -> compare with acceptance
  -> update state and context frontier
  -> continue / revise / stop

这就是 LLM-Modulo、debugging scientific method、HRO mindful updating、Lakatos proofs and refutations 的共同结构。

8. 任务设计中的关键张力

第一组张力是 context 和 budget：

要提高正确率，需要更多上下文；上下文越多，attention 竞争和成本越高。

解决方式不是“塞满上下文”，而是提高 context 的互信息密度。

第二组张力是 autonomy 和 verification：

Agent 自主性提高吞吐量；验证不足会让错误在轨迹中累积。

解决方式不是收回所有权限，而是定义可自动检查的验收器和可回滚边界。

第三组张力是 decomposition 和 coordination：

分解降低单个 agent 的认知负担；分解也制造 handoff、上下文损失和聚合错误。

解决方式是按信息依赖和验证器拆，不按组织角色或表面步骤拆。

第四组张力是 method 和 emergence：

方法论降低搜索空间；过硬的方法论会压制任务过程中出现的新信息。

解决方式是给方法论配 stop rule 和 refutation rule。方法用于引导，不用于遮蔽反例。

第五组张力是 target 和 learning：

目标必须足够明确才能执行；未知任务会在执行中重新定义目标。

解决方式是把目标写成 acceptance region，而不是固定单点答案。

9. 与 LLM 本体定义的连接

上一轮定义的 LLM 性质直接推出 Agentic Task 的设计原则：

LLM 性质	Agentic Task 推论
条件概率生成	任务契约必须塑造输出分布
attention-bounded	任务必须做 context selection 与约束预算
近似 stateless	任务状态必须外置到文件、DB、scratchpad
非自证	任务必须分离 generator 与 verifier
anchor-sensitive	任务入口必须放置正确 intent、source hierarchy 和 stop rule
高 pattern capacity	让 LLM 做候选生成、类比、方法调用和初稿，不让它单独承担真值裁决

所以任务设计不是 prompt 技巧，而是给概率 proposal engine 构造一个可收敛的问题环境。

10. 最小可用定义

最终建议使用这个定义作为后续工作基准：

Agentic Task 是人类意图在 Agent 系统中的可执行形态：它是在无限潜在上下文、有限资源预算和不完全可观测状态下，通过相关性选择、方法论引导、操作序列和验证反馈，把当前状态推进到可验收目标区域的开放式状态转化问题。

一句话版本：

任务不是指令，而是有限预算下的上下文选择与状态转化。

工程版本：

一个任务只有在写清 目标状态、当前状态、上下文 frontier、可用操作、预算、方法、验证器、风险边界、停止规则 之后，才真正变成 Agent 可执行的对象。

11. 对后续 Agent 编排的直接规则

任何复杂任务先写 Task Contract，再执行。
任何未知任务先画 Context Frontier，再读材料。
任何长任务必须外置 state，不能依赖对话历史。
任何分解都必须说明信息依赖、验证器和聚合方式。
任何开放任务都必须写 residual ledger，不能把预算停止伪装成完全覆盖。
任何高风险任务都必须提高 verifier 强度，而不是只提高模型档位。
任何方法论都必须带反例机制，防止方法压过现实。
任何完成声明都必须回到 G_eta，说明已经满足哪些验收条件、哪些仍然未覆盖。

12. 一个可复用的任务契约模板

Agentic Task Contract

Intent:
  用户真正想改变什么？

Current State:
  当前已知状态是什么？
  哪些状态未知，需要探测？

Goal Region:
  什么样的结果算可接受？
  哪些结果明确不可接受？

Context Frontier:
  必读 source:
  可选 source:
  未覆盖 source:
  权威顺序:

Operators:
  可用工具、文件、搜索、执行动作:
  禁止动作:

Method:
  本任务应使用什么方法论？
  为什么这个方法适合？

Budget:
  时间:
  token:
  费用:
  风险:

Decomposition:
  是否需要分解？
  子任务是否近似独立？
  每个子任务如何验证？

Verifier:
  自动检查:
  人工判断:
  反例搜索:
  引用或证据要求:

Feedback:
  每轮执行后观察什么？
  如何更新 state / context / plan？

Stop Rule:
  什么时候完成？
  什么时候继续？
  什么时候升级给用户？

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