现在是 2026 年 4 月 11 日，晚上。
今天 PolyMarket 套利项目正式上线了基金形式。代号是 PathFinder，简称 PF。早期也命名为 PMA。
今天与 C1 讨论了这段时间，我调度 AI 的一些心得。
我认为 Agent Harness 目前的表现其实已经抵达了甜蜜点：经过少数的访谈可以使得 AI 产生还不错的结果，不至于 100% 精准，但是不至于南辕北辙。
如果当下继续去发力 Harness 的话，完成任务的准确率可能会继续提升，但是代价会越来越大。
现在我的工作流程，通常是访谈 30 分钟左右，然后执行 1-2 小时。完成一轮工作需要做 2 小时左右。
我回过神来发现，我其实也可以没必要那么去细细地看 spec。这可以给我的访谈节省不少时间，很多时候我只需要无脑按照 AI 推荐的方向 对、对、对 就好了。
我其实可以等 AI 自然生长出这些细节来，而不是我去强行灌输给它。
为什么我认为我需要去审查呢？还是害怕 AI 走偏了。我的时间不多，我不能接受这一天的进展不利。
如果每次我提个方向，几分钟对对对之后，又过了几分钟，事情全部搞定了，那我就完全没有必要去审查了。此时就完全不如放手让 AI 自然生长了。
因此，我认为，现在 Harness 已经不是主要问题了。迭代速度才是主要问题。介于当前 AI Token 仍然很便宜，经济成本暂时仍然不是问题。
我认为一个项目应该是从它的 init commit 开始，从这个 origin/main 的 ref 上，不断通过 PR 线性长出来的。
OpenCode 的一轮会话可以从任何的一个 origin/main 开始，根据任务的上下文，开一个新的 worktree，执行任务，集成测试，完成后提交 PR，解决冲突，合并到 origin/main 上，清理 worktree。
这个任务它已经能比较好地完成了。
我们不妨将这个任务作为一个调度的基本单位。
我们需要去将任务拆分并建立依赖管理，构建一个任务图，每个任务可以绑定到一个 OpenCode Session 上执行。
任务根据依赖关系会分为无阻塞和阻塞的，当然这种分类仅仅是概念上的。我们不可能真的 100% 确定一个任务和另一个任务之间的依赖关系。
实际上，所有的任务都可以并行执行，但是有些任务最好是等待其他一些任务完成了再去执行，这件事也是交给 AI 来判断的（因此不会 100% 准确）。
甚至一些任务表面上是被阻塞了，但实际上它还能拆分成更小的任务来并行执行，有一些是阻塞的，而有一些是无阻塞的，这些都是 AI 来判断的。
一个典型的例子是，一个涉及前端、后端、接口的综合功能开发任务。它可以被拆分成前端开发、后端开发、接口设计三个子任务。前端开发和后端开发可以并行进行，它们都依赖于接口设计的完成。因此，接口设计是一个无阻塞任务，而前端开发和后端开发是阻塞任务。
还有一个观点是，错误地推进一个本该被阻塞的任务时，在传统调度里是不可接受的，但在 AI 调度里是可以接受的。就像人一样，它可以 standby 在这个任务上，等待所有的依赖任务都完成了。
AI 自己在执行任务的过程中，也能检查这个环境是否已经符合执行条件了，如果没有，它就会创建一个前置任务来改造这个环境，直到满足条件了它才会继续执行这个任务。
因此，与其说拓扑排序是调度的核心，不如说它只是一个启发式的工具。如果你有无限多的 AI Token，你可以 fork 出无数个 work-tree busy spanning 在不同的任务上，AI 会自己去判断。
