这是一套 LLM 驱动的任务运行时——路由、执行、自愈全部自动完成。一个 Markdown 文件作为 Agent 的控制平面，整套系统不依赖于任何打开着的会话——编辑文件后，工作会在后台继续。下面讲清楚：这套架构的设计思路、我做出的几个关键取舍、实际运行数据，以及一个我没有刻意编程、系统却自发表现出的关键行为。
背景：作为一个独立运营者，我同时在推进 4 条线（内容生产、首位客户的架构评审、作品集搭建、学业）。任务状态散落在不同工具里——每次切换上下文都要花 15–30 分钟重新进入状态，才能真正开始工作。
产品约束：我想要的任务系统需要满足两点：可以随时加任务；分配给自动化的任务能自己跑完，不需要我守在电脑前。合上电脑，几个小时后回来，任务已经处理完。
为什么这是 Agent 设计的关键：大多数"AI 助手"一关上聊天窗口就停止工作——它们绑定的是对话，而非工作本身。构建一个不依赖会话生命周期的 Agent 运行时，是一个完全不同的设计问题；这也是让 Agent 从"工具"升级到"基础设施"的分水岭。
核心设计问题：一个纯文本文件 + 一套状态机协议 + 一个 LLM 决策层，能不能撑起一个持久化的 Agent 运行时？如果可以，这套模式就能迁移到任何运营工作流——客服工单分派、内容流水线、业务自动化。
task-board.md 被编辑（任何来源：我、另一个 agent、cron）fswatch · 2 秒 debounce · launchd 每小时兜底mkdir 原子操作ready / blocked:* / running:* / done / failed:*task-board.md 写回 · events.jsonl 结构化日志 · deadletter/ 终态失败归档4 个刻意做出的取舍。每一个我都列出了明确拒绝的替代方案。
ready / blocked:siyao:send-brief / running:agent-a4b:2026-04-20T15:25Z / done / failed:exhausted_retriestask-board.md + 分布式锁机制（flock、append 模式、CRDT）基线追踪 2026-04-20 启动。数据来自首周运行；部分为初始数据估算，方法论已标注。
events.jsonl——从保存到 file_changed_triggered 事件running:* 状态自动重置。零手动介入。launchd 在笔记本运行）系统前：手动查任务清单 + 常规研究任务约占 8–12 小时/周。系统后：常规任务（竞品调研、文档起草、市场扫描）被路由到并行 subagent，无需实时督促。
首周观察产出：5 项实质性研究/写作任务在无监督情况下完成（代表例：260 行竞品分析、895 行架构 case study、18 份 JD 市场扫描、HR 视角作品集评估）。
方法论：效率估算基于自报基线。精确量化从第 2 周开始（进行中）。
我给决策层的编程只有一件事：找 ready 状态的任务，执行它们。其他一律跳过。
首次生产运行时，它做了我没有编程的事：
blocked:task:TASK-015，但 TASK-015 已经是 done。skill 标记"依赖链断了"，建议把它升为 ready，并问我这是否符合我的意图。ready 的任务，skill 对比 Measure 字段和可用输入，注意到一个必须的产出物（portfolio URL）缺失，拒绝执行——等我澄清。running:claude-a:2026-04-20T15:25Z 实际是本地时间被错标为 UTC。skill 计算出这个时间戳比 now 领先 2 小时，标为 anomaly 问我确认。这些行为都不在 prompt 里。它们从状态机设计中涌现出来。
同一个 LLM，同一张 task-board，agent 的行为可以截然不同——全看 status 是标签还是协议。自然语言 status（"等待"、"进行中"）给模型的只是一串可以 pattern match 的文本；类型化 status + 结构化子字段，给模型的是一套可以推理的协议。给产品团队带走的核心结论：让 agent 从"执行机器"进化成"推理搭档"，真正的杠杆在结构化的状态协议，prompt 只是最后一层调优。
这对 agent 系统设计的含义很具体：多数团队在 agent 行为不满意时，第一反应是去迭代 prompt。但更高杠杆的动作，往往是修改 agent 所运行的那个类型系统本身。
这套架构不是任务自动化专用的。同样的 5 层模式（控制平面文件 + 事件驱动调度 + 无状态执行器 + 类型化状态机 + 只追加审计日志）可以直接对应到一位 Shopify 客户在简报里提出的几类工作流——我正在为这份简报做架构评审：
| 工作流 | 控制平面 | 决策层任务 |
|---|---|---|
| 客服工单分流 | Helpdesk ticket 队列 | 分类 + 起草回复 + 标记待审核 |
| 预售订单管理 | 供应商 ETA 追踪表 | 识别变动 + 生成客户通知 |
| 供应商数据产品创建 | 接收表格队列 | 字段抽取 + 标准化 + 写入草稿 |
| Collection-buying 收品 | 咨询邮件日志 | 抽取 + 评分 + 起草跟进 |
同一套状态机规范（ready / blocked:* / running:* / done）对每一种都适用。真正与具体工作流相关的只有决策层的 prompt 模板——基础设施完全可以共享。
launchd 托管一个本地 HTML dashboard，展示任务吞吐量、错误率、延迟分布等指标随时间的变化events.jsonl 里哪怕是粗糙的计数器，也比事后补的精确指标有价值——事后补的数据永远只能是估算搭完这套系统之后，我收获了一条可以带到任何 agent 产品里的结论：状态机本身才是产品。Prompt、subagent、调度层都是可替换的；真正持久、真正能规模化、真正决定"这个系统只能执行还是能推理"的，是人类意图和 agent 行动之间那份状态契约。
首先讲清定位：这是一个单人使用的运行时，为我自己的任务流定制，而不是一个平台产品。它要解决的是"一个人协调一小组工作流"这种非常具体的场景。写第一行代码之前，我真正需要回答的问题不是"要不要做一个 Coze 的竞品"——而是"现有工具里有没有已经能解决这个场景的？如果有，是哪一个？"下面是我做决定前的分析。
blocked:task:TASK-010 表示 TASK-010 还没完成——模型可以自己去验证），而不是颜色标签或自由文本 status。这三个平台都把工作流抽象在一个 UI + 一套 schema 的后面，让你通过 UI 去配置。当操作者是非技术人员、状态需要跨团队共享、或者工作流本身就是产品时，这是对的选择。但这些条件在我这里都不成立。对一个独立操作者、且工作流状态本来就是文本的场景而言，引入第二套状态系统（画布 + 厂商存储）的成本，会超过预置节点带来的便利。
换个角度说：这套运行时之所以是大约 300 行 shell 脚本 + 一个 skill 定义，而不是一套 Dify 部署，并非因为我觉得自己能做得更好。真正的原因是：我的场景（单人、Markdown 原生、终端原生、零厂商依赖）恰好是这些平台刻意不去优化的边角情况。对它们真正的受众——跨职能团队要交付面向用户的 agent 产品——它们才是对的选择，我也会推荐。
这里可以迁移的能力不是"我能做一个比它们更好的平台"。真正可迁移的是一套判断方法：在写下任何一行代码之前，先列清自己真正需要的几件事，把每个现有工具逐一对照——只有每一个工具都在某一条上失败时，才选自建。这套 build-vs-buy 的判断框架，放在产品岗位上做任何 agent 平台决策都同样适用——包括在现有工具已经覆盖场景时，明确给出"不要自建"的建议。
张思瑶 · 2026 年 9 月入职，北京 · 与我联系