推文

@fireandstart · 2026-10-11 13:09

这条帖子的关键不只是把一串步骤换成 DAG，而是把代理工作从“照着一份越来越长的提示词做事”，转成“声明目标、依赖和完成条件”。日志与差异不断进入上下文时，编号清单容易发生位置漂移：模型看起来仍在执行原计划，实际引用的步骤、产物或先决条件却已经变了。显式的依赖关系让流程至少能回答三个问题：现在要交付什么、它依赖哪些前置结果、哪些部分在上游变化后必须重算。 Makefile 的类比也很实用。它不要求执行者记住一整段叙述，而是把目标与构建关系写在可检查的结构里；某个输入改变时，只重做受影响的部分。放到代理工作流里，这意味着把研究、改文件、运行命令、汇总证据拆成边界清楚的节点，并留下可追溯的输入输出。真正的收益可能不是“代理更聪明”，而是错误更容易定位，重试的范围更小，交接时也不必重新猜它前面做过什么。 当然，143 个生产工单是一个值得关注的信号，但不能单独说明 DAG 对所有任务都更好。依赖关系若建错，形式化只会让错误更稳定；任务频繁变化时，维护图结构也可能比短清单更贵。实际落地应该观察返工率、失败后恢复范围、无效重跑比例，以及人工接管前能否复现执行路径。对简单的一次性任务，轻量提示仍够用；当任务跨多阶段、共享状态并需要可靠恢复时，把流程写成可验证的依赖图才真正开始划算。

曝光 93 · 评论 0 · 点赞 1 · 书签 0 · 曝光/时 69.84351438376169