给本地 Agent 造一块看板（三）：任务图派——把「下一个任务」变成一次查询

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖 steveyegge/beads、eyaltoledano/claude-task-master、bmad-code-org/BMAD-METHOD。 元数据于 2026-10-08 经 GitHub API 一手核验。

一、这一派放弃了看板

上一篇的文件系统派，本质是「把看板换个存储介质」。任务图派的野心更大：它认为看板这个隐喻本身就是错的。

看板的说法是"一张张卡片，从左边流到右边"。这个隐喻隐含了一个假设：任务之间是独立的。它默认你拿起最左边那张卡就能做，不需要等谁。

真实的多 agent 场景里，这个假设经常不成立。“写部署文档"要等"接口定稿”，“跑基准测试"要等"数据集清洗完”。如果看板不知道这些依赖，那么 agent 取任务时就只能按创建顺序或一个优先级数字去猜——它随时可能取到一个"前置条件还没满足"的任务，然后在那里空转、报错，或者更糟：基于不存在的产物瞎编。

任务图派的回答是：别猜，把它算出来。 把依赖显式建成图，然后提供一个查询，直接返回"当前真正可以开工"的那批任务。

在上图里，绿色的 T1 已完成；黄色 T3 虽然前置已满足但依赖另一条链；红色的 T4 被 T2 阻塞。问题"我现在该做哪个"的答案，就是所有"前置全部完成"的节点集合——术语叫就绪集（ready set）。

给本地 Agent 造一块看板（四）：极简单机派——一个二进制、一条命令

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖 rgracey/kanban-mcp、nerkoman/agent-kanban、mintopia/cocopilot、AdamManuel-dev/task-kanban-mcp、SimonBlancoE/kanban-mcp。 元数据于 2026-10-08 经 GitHub API 一手核验。

一、这一派的共同追求：把"部署"这件事消灭掉

前两派都在解决"看板该放在哪"（仓库里 / 依赖图里）。这一派不关心这个，它的目标极其单纯：让一个人在一台机器上、用一条命令，把看板立起来。

于是它们的形态高度一致：

一个进程、一个 SQLite 文件、一个 HTTP 面（外加可选一个 MCP 面）。没有 Docker、没有外部数据库、没有鉴权体系。

这个追求是合理的——本系列的目标场景就是"单人单机"。但这一派的表现也最参差：它的能力上限不低（有的做到了相当完整的自动派单），可它的存活率是全系列最差的。

先把项目摆出来。

二、五个项目逐个看

2.1 rgracey/kanban-mcp（2★，无许可证，Go）—— 部署轻量度的满分答案

它是"单二进制"这个形态的教科书。

一个 Go 二进制里，SQLite + Web UI + MCP server 全部内嵌，零外部依赖，Web UI 在 :8080。功能上也有几个亮点：

给本地 Agent 造一块看板（五）：自主编排派——三个最接近目标的项目

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖 cline/kanban、saltbo/agent-kanban、BradGroux/veritas-kanban。 元数据于 2026-10-08 经 GitHub API 一手核验；机制描述取自各仓库 README 与架构文档原文。

一、为什么这一派要单独成篇

前面三派各自缺一大块：文件系统派缺守护进程与验收；任务图派只解决调度决策；极简单机派几乎没碰 C5–C7。

这一派不同。这三个项目都明确主张同一件事：把人从执行环路里拿出去。

• cline/kanban 的措辞是"更适合并行跑大量 agent 并审查 diff 的 IDE 替代品"；
• saltbo/agent-kanban 的标语直接是 “Don’t babysit your agent. Take human out of the loop.”；
• veritas-kanban 则是"local-first 的任务管理看板 + 可选的 AI agent 编排层"。

而它们的覆盖度也确实更高——其中 veritas-kanban 是本系列唯一一个同时具备"配额预算"与"产出评分"的项目，这直接推翻了早期调研"C6/C7 完全空白"的判断（详见总览篇第二节）。

需要坦白一件事：这三个项目在前几轮检索里全部被漏掉了。 漏掉的原因很简单——检索词一直围绕 kanban 打转，而这三个项目的自我描述分别是"IDE replacement"、“mission-control board”、“task management board with agent orchestration”，名字或描述里根本没有那个词。

这本身就是一条方法论结论：当你要找的是"机制"时，用"名字"检索会系统性地漏掉最好的答案。 所以本篇开头先把这个教训摆出来。

二、三个项目逐个看

2.1 cline/kanban（1,353★，Apache-2.0，TypeScript，标注 Research Preview）

它的关键词是"链"。

用法极简：在任意 git 仓库根目录跑 npx kanban，它会自动探测你本机已安装的 CLI agent，然后在浏览器里起一个本地 Web 服务。无需账号、无需配置。

给本地 Agent 造一块看板（六）：多 Agent 工作台派——派单模型与认领模型的分野

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖 iOfficeAI/AionUi、DanWahlin/ai-agent-board、smtg-ai/claude-squad、Nimbalyst/nimbalyst、langwatch/kanban-code。 元数据于 2026-10-08 经 GitHub API 一手核验。

一、这一派是最"像产品"的一批

如果说前面几派是"给工程师用的工具"，这一派就是"给人用的产品"：有像样的界面、有自动探测、有向导、有通知、有移动端。

它们的共同强项高度一致：

• C1 看板呈现：拖拽、实时流式输出、diff 查看器、行内评论，体验是全系列最好的；
• C4 异构 agent 驱动：启动时自动探测本机已装了哪些 CLI，这是本派最实用的一项能力；
• C5 执行隔离：worktree 隔离几乎是标配，且往往配了自动清理。

它们的共同软肋也高度一致：C2/C3（自主领取与扫描）与 C6/C7（验收与额度）基本不在射程内。

而这一切背后有一个更本质的差别，本篇的主要论点就围绕它展开。

二、核心分野：派单模型 vs 认领模型

先把这个区别讲清楚，因为它解释了本派为什么"功能很多，却依然不能无人值守"。

这个区别对本场景是决定性的。 因为本场景的动机是"让多个 agent 长时间持续运行、吃满各家免费额度"——这要求系统能根据 agent 的可用性动态分配任务，而不是由一个 Leader 预先分好。认领模型天然适合这件事；派单模型天然不适合。

给本地 Agent 造一块看板（七）：平台内置派——当看板成为 Agent 运行时的一等公民

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖 NousResearch/hermes-agent（252,141★，MIT）内置的 Kanban。 机制描述取自本机安装目录中的一手文档（website/docs/user-guide/features/），非二手转述。 ⚠️ Hermes 迭代极快，本文所有路径、环境变量名与配置项均为 2026-10-08 快照，实际使用前需重新核对。

一、这一派只有一个样本，但它的位置很特殊

前面五派有一个共同前提：看板是一个外挂工具。 它可能住在你的仓库里（文件系统派）、住在数据库里（极简单机派）、或者带一个漂亮的桌面界面（工作台派），但无论哪种，它站在 agent 的外面：它负责记状态，然后想办法去调用 agent。

平台内置派的前提完全不同：看板长在 agent 运行时内部。 它不是"一个会调 agent 的看板"，它是"一个自带看板的 agent 平台"。

这个位置的差异，直接决定了能力上限。用一句话概括：

一个独立看板只能"调用 CLI 并解析输出"；而一个拥有 agent 生命周期的看板，可以"回收一个 PID 已经消失的 worker"。

举个具体的例子。所有独立看板项目都在某个地方承诺"任务超时会自动释放"。但它们能做的其实只是"把 claim 时间戳过期的任务标记为可领取"。而 Hermes 的 dispatcher 做的是：

• 定期回收过期的 claim；
• 并且专门回收"PID 已经消失、但 TTL 还没到"的崩溃 worker；
• 还有一个反直觉的细节——只有进程真的死了才回收。也就是说，一个跑得很慢但活着的模型会被续期，而不是被杀掉。

这三条之所以能做到，是因为 dispatcher 本身就持有 spawn 权。 它 spawn 了那个 worker，所以它知道 PID；它能探活，所以它能区分"慢"和"死"。外挂式看板永远拿不到这个信息——它启动 CLI 只能拿到一个子进程句柄，而那个句柄在 CLI 内部又 fork 出什么，它一无所知。

这一篇的全部价值，就在这个"位置差异带来的能力差异"上。

给本地 Agent 造一块看板（八）：日落的教训与横向对照

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖 20 个开源任务看板 / 编排项目。 本篇分四部分：日落复盘、横向矩阵、跨项目启发、选型与缺口。 元数据于 2026-10-08 经 GitHub API 一手核验。

第一部分：一次有意识的商业止损

1.1 事实

先把事实摆清楚，全部来自一手核验。

README 顶部的原文是一句加粗的 <strong>Vibe Kanban is sunsetting.</strong>，后面跟着一个指向官方博客关停公告的链接。

它是全系列里星数第二高的项目。 一个 28,292★ 的项目，在创建不到两年后主动关停。

1.2 它解决的是什么问题

要理解它为什么死，先要看准它做的是什么事。它自己的 Overview 写得很清楚：

In a world where software engineers spend most of their time planning and reviewing coding agents, the most impactful way to ship more is to get faster at planning and review. … Use kanban issues to plan work… When you’re ready to begin, create workspaces where coding agents can execute.

Meta Muse 拆解：消费级 Agent 的玩法全解，与上线六周暴露的七个问题

2026 年 9 月 8 日，Meta 发布 Muse，自称「世界首个为所有人打造的个人 AI Agent」。六周之后，它交出的成绩单是双面的：美国日活约 60 万、专用硬件 Muse Charm 定档 12 月发货；同时它也比任何一个同类产品更快地踩中了地址外泄、零日漏洞、被电商平台封禁、被指抄袭开源框架这一整串问题。

这篇文章不站队，只做一件事：把 Muse 的产品设计、技术架构和商业模式拆开，让你看清一个消费级 Agent 到底是怎么运转的，以及这套设计在哪里漏了风。

一、30 秒结论

1. 它是什么：一个「执行型」而非「对话型」的个人 Agent。用户告诉它要完成什么，它自己去开浏览器、填表单、发邮件、谈价格、下单付款；关掉 App 也继续跑，只在敏感动作前回来找你要授权。
2. 最有价值的设计：Muse Secure VM + Sentinel 双 Agent 架构。每个用户独占一台云端虚拟机，另有一个系统级隔离的守门 Agent，Muse 的任何出网动作都要经它批准。这是目前消费级产品里对「Agent 越权」最认真的一次工程回应。
3. 最有商业含义的动作：支付走 Stripe Link，且是第一个被 Link 购买保护覆盖的 AI Agent——虚拟一次性卡号、丢件/降价/退货有保。Meta 明确说长期变现靠交易抽佣，不是订阅费。
4. 最能说明问题的部分：六周内的七个事故。它们不是孤立的运维失误，而是指向同一个结构性矛盾——给 Agent 的权限越大，可被诱导的路径就越多。
5. 一个关键背景：Muse 的文件体系（SOUL.md、memory、tools）与开源 Agent 框架 OpenClaw 高度同源。理解这一点，才能理解它的安全边界是从哪来的。

二、它到底能替用户做什么

先交代一个容易被忽略的前提：Muse 由 Meta 自研模型 Muse Spark 1.3 驱动（该版本 9 月 2 日发布，官方称其主打真实世界的 agentic 工作）。产品和模型共用「Muse」这一系列名，意味着 Meta 走的是自研模型 + 自研 Agent 的垂直整合路线——这一点与后文要对照的 Manus 恰好相反。

Manus 2.0 拆解：Cascade、云电脑与 Cue——把 Agent 做成「卖电脑的生意」

2026 年 9 月 28 日，Manus 发布 2.0。此时距它 9 月 1 日正式恢复独立运营，只过了 27 天。

官方开篇第一句就把调子定死了：「Manus 2.0 不是一次版本更新。它是围绕一个根本问题构建的新架构、新产品和新能力：下一代 Manus 应该是什么样的？」

这篇文章要回答的是：这个「全家桶」里，哪些是真变化，哪些只是把已有能力重排了一遍；以及为什么它和同月上线的 Meta Muse，走的几乎是相反的两条路。

一、30 秒结论

1. 最硬的一项：自研 Agent 框架 Cascade。官方数据是 token 消耗降 23.2%、任务耗时降 28.2%、运行成本降 32%——注意官方同时声明这是单项测试配置的结果，不是全场景平均，这个自我限定比数字本身更值得注意。
2. 最实用的两项：Cloud Computer（可购买的云电脑，让项目在用户合上笔记本后继续跑）与 Automations（把「定时任务」升级为「事件触发」——一封邮件、一条 Slack 消息、一次 Notion 更新都能启动工作流）。
3. 最有想象力的一项：个人 Agent 产品 Cue。每个 Agent 拥有独立的邮箱、电话号码、钱包和自己的电脑，可以在预算内付款、代接电话并留摘要，还能把多个 Agent 拉进同一个群聊协作。
4. 最好记的一句定位：创始人肖弘说「我一直觉得 Manus 挺像是一个卖电脑的生意」——工作之外也得能看视频、打游戏。这句话解释了 2.0 为什么要把视频、游戏、远程控制全塞进来。
5. 和 Meta Muse 的分野：Muse 追求「尽可能多的人」，用 WhatsApp 触达二十亿用户；Manus 追求「尽可能深的活」，把 Agent 做成一个可购买、可常驻、可协作的工作空间。

二、Cascade：这一版的重点，是「省」

Agent 框架这个层面，用户的感知最弱，但它决定了产品的成本结构和上限。

DeepSeek 开源昇腾版 TileLang：一份写给非底层读者的阅读指南

2026 年 9 月 30 日，DeepSeek 官宣开源一批面向华为昇腾算力平台的基础设施组件：TileLang 高级语言编译器、计算库、分布式通信库，共六个组件，与它此前面向英伟达平台开源的那一套「一一对应」。

这条新闻在国内被反复转述为「对标 CUDA」。这个说法方向对、程度夸。本文想做的事只有一件：让没写过 CUDA、也没碰过昇腾的读者，读完之后能自己判断这类新闻里哪句是事实、哪句是厂商自评、哪句是媒体加的戏。

一、30 秒结论

先把答案给出来，后面全是展开。

1. 发生了什么：DeepSeek 把自己训练和推理真正在用的那套底层软件，从英伟达平台搬到了华为昇腾平台上，并且开源了。核心是编程语言层（TileLang），外围是六个可直接调用的库。
2. 为什么重要：英伟达真正难被替代的不是芯片，是芯片外面那层软件。别人能做出一块算力接近的卡，但做不出「让四百万开发者不用重新学习就能把模型跑起来」的那层东西。这次是模型厂商第一次把自己吃饭的家伙下沉到国产芯片上，性质比「适配一下模型」重得多。
3. 哪句要打折：所有性能数字都是厂商自评，没有第三方基准；跑出那些数字用的还是非公开的 PoC 固件；官方没有说 V4 已经在昇腾上完成了全量训练。
4. 一句话定位：这不是「国产 CUDA 建成了」，而是「国产芯片的软件生态，第一次有了一个由顶级模型团队亲手填上的、可用的关键零件」。

二、补三个概念：写给不写底层代码的人

要读懂这条新闻，只需要三个概念。它们都有日常类比。

2.1 算子（kernel）：AI 芯片的「招式」

大模型跑起来，本质上是无数次的矩阵乘法、加法、数据搬运。每完成一个不能再拆的基本运算单元，就叫一个算子（英文 kernel，直译「内核」，但在中文语境里叫算子更准确）。

类比：如果 AI 芯片是一台厨房设备，算子就是一套固定的刀工——切片、切丝、剁馅。市面上有现成的刀工（框架自带的算子），但顶级厨师遇到特殊食材时，必须自己设计一套新刀法。这套新刀法就是「自定义算子」。

关键点：算子的效率决定了芯片效率。 同一块芯片，算子写得好能跑到理论性能的 99%，写得差可能只有 30%。芯片参数的差距，经常被算子水平的差距盖过去。

2.2 编译器 / DSL：从「人话」到「机器指令」的翻译官

直接对着芯片写指令，等于让人用汇编语言写 App——不是不行，是太慢太痛苦。于是有了编译器：你用一门更接近人话的语言描述「我要做什么」，它负责翻译成芯片能执行的指令，并顺手做优化。

这门「更接近人话的语言」如果只为某个领域服务，就叫 DSL（领域专用语言）。TileLang 就是这类东西，而且是 Python 风格的——这一点很重要，因为后面所有性能优势都来自「写起来像 Python，跑起来像手写汇编」。

2.3 CUDA：英伟达真正的护城河

CUDA 是英伟达的编程语言 + 整套工具链。它之所以是护城河，不是因为语言本身多优美，而是因为：

• 十几年积累的库、调试器、性能分析器、文档；
• 几乎所有 AI 框架都优先支持它；
• 据《纽约时报》估计，全球约 400 万开发者 已经会用它。

换一块卡容易，换掉这 400 万人脑子里的东西很难。这就是为什么「国产芯片」的瓶颈常常不在算力，而在软件。

阿里云电力 AI 调研（一）：总览——全栈版图与产品矩阵

本系列共八篇，逐环节拆解阿里云在电力行业「发、输、变、配、用」的 AI 与 Agent 落地现状。 全部结论标注信源等级：A 官方（阿里云/客户官网、官方技术博客）、B 权威媒体 / 行业白皮书 / 信通院、C 厂商 PR 稿或会议演讲、D 二手转载（仅作线索）。 本系列刻意区分「已投产」与「方案宣传」，并对厂商口径保留独立判断。

一、为什么要做这个调研

「AI + 电力」是 2025—2026 年 to-B 领域声量最高的赛道之一。阿里云在这条赛道上的位置看起来非常牢固：2025 年 9 月云栖大会披露，中国超 70% 的能源央企已接入阿里 AI，阿里云已与所有能源央企建立合作（C，阿里云政企业务稿）。

但这个数字经不起细看。同一主题在 2026 年的现场推进会上，口径已经变成了 80%——这本身就是一个典型的信源漂移。更关键的是，“接入"是一个极低成本的动作：买了云、部署了平台、跑了一个知识库问答，都可以叫"接入”。它对回答下面这些真正重要的问题毫无帮助：

• 哪个环节做到了可验证的生产级落地？哪个环节还停留在方案卡片阶段？
• 那些亮眼的效率数字（“效率提升 8 倍"“准确率 98%"）究竟是谁的成果？AI 在其中贡献了多少边际价值？
• 电力这种强安全约束行业，大模型的幻觉问题是怎么被工程手段压住的？
• 一个省级电网能用的东西，一家地市供电局或者一家民营新能源企业能不能用？

本系列的定位是做一次「可核查」的梳理。 不重复厂商稿的叙事结构，而是把每个案例按"客户主体 → 时间线 → 可查数字 → 信源等级 → 归属判定"逐项过一遍，该说"未找到公开信源"的时候就直说。

二、三条总结论（结论先行）

读完八篇之后，最值得记住的是这三条。它们是全系列的骨架，各环节篇的细节都可以挂在这三条下面。

结论一：版图是「底座强、应用分层不均」

阿里云的电力 AI 产品是三层结构：算力与数据底座层、模型与平台层、智能应用层。这三层的证据强度完全不同：

• 底座层与平台层证据最足。飞天企业版、百炼专属版、通义系列模型都有官方文档级的公开信息，技术细节可验证（详见第七篇）。
• 应用层差异极大。同样是"五环节”，用电侧的公开可查案例数量是输电侧的数倍。输电侧甚至找不到一个阿里云主导的线路本体视觉识别客户案例（详见第三篇）。

所以"阿里云电力 AI 解决方案"这个说法，实际上是一个平台 + 若干不均匀落点，而不是一张均匀铺满五个环节的网。

结论二：客户侧是解耦的多供应商格局

这是本系列最重要的一条方法论。不要把客户的技术栈整体归给某一家厂商。