大模型的发展仍然在突飞猛进，回顾一下这7个月的变化，真的非常惊人。

虽然agent从年初的glm4.7,到现在chatgpt5.6, 大模型(及其harness)的进展已经很惊人了，但如何去用 agent 真正实现价值，仍然是挺复杂的问题。具体来说：你可以用很简单的语言让codex 帮你完成项目。然后随着时间推移，你会发现许多功能似乎需要修改，于是需要不停的修修补补。这个过程中你会进一步发现还是离不开人，每一步几乎都要你确定。所以最终从体验上来说，codex也没有完全解放生成力。

agent已经提升了我们的生产效率，但是提升的幅度不大。从时间上看，我们的时间仍然要绑在项目进程中。

所以，这篇文章想探讨一种机制，基于这种机制，需要能够解决以上的问题：把人的时间进一步从项目进程中解放出来。只有在里程碑阶段才需要人类的参与，或者是出现异常情况才需要人进行简单确认。

我基于一些实践，认为 TOE-DAC框架应该是可行。本质上这个是符合强化学习的框架的，且留下了必要的可追溯痕迹，这样既有稳定的迭代方法，也有足够清晰的定位方法，即对于人，也对于agent。

TOE-DAC 是一种面向长周期 Agent 任务的、可持久化的分层控制协议。它以 Target、Observe、Estimate、Decide、Act、Check 为主循环，通过状态机、证据链、父子任务契约、预算约束和异常恢复机制，使 Agent 能够在明确授权范围内持续推进任务，只在里程碑或不可自动恢复的异常处请求人类参与。

TOE-DAC框架是一个线性的流程，规范化了人类决策行动的关键步骤：

• 1 Target：定义成功不负责选择实现路径。包含了正向的描述，反向描述，以及评估方法.
• 2 Observe：收集事实，不对方案作最终判断。观察当前的相关环境，收集与目标相关的信息.
• 3 Estimate：评估可行性、风险、成本和信息缺口。根据Target和Observe, 估计可执行性，提供决定是否进入实际的规划和执行阶段的必要信息。
• 4 Decide：生成或更新行动图，确定依赖、预算和升级条件。根据前面三个阶段的结果，来进行计划。这一步需要是可解耦的，形式上，是可以通过json将数据发往某个api，然后得到一个具体的执行列表（逻辑拓扑列表）。因为面对(TOE), agent 需要根据经验(既有通用知识，也有实际的经验)作出判断。
• 5 Act：执行一个原子行动，并产生结构化结果和证据。执行，对decide 确定好的任务(列表) 进行持续化的执行(agent loop)，每一次都包含了具体的执行目标、期待执行结果的断言、失败后的重试(非简单重试，而是带有路径探索的重试)
• 6 Check：验证结果是否满足行动断言及上层目标。

其中最重要的是区分两种检查：

• action_check：这个动作是否按预期完成。
• target_check：动作即使完成了，是否真的推动或实现了目标。

整体上大约是这样：用户/agent 给到了一个需求, 受理的agent按照规范将这个需求分解的更加严密和清晰；然后在开始执行前先观察相关前提条件是否满足要求，围绕这点开始进行信息收集；完成收集后，开始进行评估基于目标和观察的结果进行可行性的估计。完成这些后，前半部分完成，此时agent开始真正进行决策，选择最佳的解决问题路径，这应该是一个 action list。对这个list进行循环，由于每个action给到了具体的行动方法，agent开始进行具体的act - check 模式，在碰到失败时，允许agent进行若干次尝试(收到次数或者budget的限制）。

框架确保了agent在执行时将问题分步骤分开，但是还没有讨论到留痕，也就是工程化的问题。

以下从三个要点来展开工程化的讨论：

• 1 时间线：通过层级日志顺着时间线记录
• 2 会话模式：相同场景下的会话可多次进行
• 3 证据：通过日志和截图两种方式进行证据留存

1 文件结构

每个用户的时间集合成为一个用户线头(User Thread), 这是TOE-DAC 工程的入口

文件结构如下：

对应的业务场景是这样：

① 用户和agent对话，首先需要确定用户线头。agent需要判断是新线头，还是老线头。使用short uuid 作为线头唯一标志符就可以。
② 如果是一个新线头，那么闯进toe-dac实例(之后简称td实例)，否则载入实例。实例的本质是状态机，因此可以随时断续执行
③ 实例有状态：实例的状态包含了和任务相关的信息，通过反复轮询状态，达到do until done 的效果。
④ 实例有日志： event.log 记录了实例 所经理的时间，包含系统部分（如启动，休眠），也包含了业务事件。描述了实例在什么时候运行，做了哪些业务操作。
⑤ 实例的每次执行都是一次会话。会话是可持久化的，特征在于保持上下文。无论是通过opencode这样的客户端，或是自定义的结构化字段(focus.json),或者是通过rmux这样的工具。
⑥ 实例的执行一定会有产出放在 artifact 下。

2 层级式 td

从实际的应用触发，要达到人的任务复杂度，需要层级式的结构，并用动态规划的方法推进。

先讨论最简单的两层结构，这样就可以衍生到无数层。

一个场景如下：

① 用户： 帮我搭建一个multica项目，参考x-001 资料( user thread)
② 父td 实例化过程（父实例进进行规划、验收，不进行具体的执行）

• target : 目标建立… 查阅资料(x-001） … 明确了各要素（不确定则抛出）
• observer: 搜集信息 … 看各要素是否具备
• estimate: 从目标和条件的角度评估是否可行
• decide: 制定了一套方案… 建立容器、启动服务、蓝绿配置
• act : 完成方案规划
• check：自检，从是否能完成目标的角度出发考虑，然后请求上级(人类、授权agent) 验收

③ 子td 实例化过程(例如：建立容器)

• target : 目标建立…
• observer : 搜集信息… 主机连通性、镜像存在性
• estimate : 估计：是否可按要求，建立起对应的容器
• decide: 决定方案… 连接，docker 命令
• act: 执行命令
• check: 自检，命令执行无错误，容器在一段时间后出现在docker ps里。通知父td验收。

要满足父子td的模式，需要td的基本属性要有parent_td(自己是父td时该字段为空)， td 实例本身需要进行持久化和统一化管理，所以需要有api进行统一管理。

另外异常处理事比较重要的，在任何一个阶段都可能发生失败，需要有应对机制和记录机制。

例如： target-fail, observe-fail … 这些失败需要分类，然后有针对性的应对方法。 human-interrupt、agent-interrupt、agent-simple-retry、agent-auto-retry。

异常处理

异常处理的问题来源是td，过程中的处理记录会在入职里，但更重要的是这些异常处理会结构化后进行累积、检索和更新。

• a 标准的字段包括 user_thread、parent_id、session_id、result_status、duration等，可用于回溯到某个时空点，重现问题所描述的细节
• b 可检索字段包括问题分类，target 的描述(向量匹配)
• c 效果字段。记录这些异常处理(经验)，这样td系统会自动的变得更好用

篇幅有点长了，总结一下 ：

结论

TOE-DAC 的核心价值，是把 Agent 从一次性的“对话执行工具”转变为可持续运行、可中断恢复、可追溯验证的任务系统。它通过标准化决策流程、分层任务结构、状态持久化、证据留存和异常恢复，让 Agent 能够在授权和预算范围内自主推进长周期任务，从而把人从频繁的过程确认中解放出来，只在关键里程碑、高风险操作或不可恢复的异常发生时介入。

下一步

下一步不宜继续扩展概念，而应实现一个最小可运行版本：

• 1 定义 TD 状态机以及 TOE-DAC 各阶段的转换规则。
• 2 定义 state、plan、action、check 和异常记录的 JSON Schema。
• 3 实现单层 TD 的持久化、恢复、日志和证据管理。
• 4 加入执行预算、路径重试、重新规划及人工升级机制。
• 5 选择一个真实任务完成端到端验证，再扩展父子 TD 和经验检索。
  首个版本的验证标准是：Agent 能够在一次人工授权后持续执行任务；中断后可以恢复；失败后可以有限度地自主探索；最终结果能够通过证据复核，并且只在预设条件下请求人工介入。