Agent 工作台的下一站是任务中心，但求你别再搞看板和群聊 Cosplay 了

原文链接：https://mp.weixin.qq.com/s/kERYFTbkP1xdOZPSBYkRaA

产品设计要回到第一性 「人的注意力」管理，而不是与 Agent 玩那些 cosplay

距离上一篇文章过去了一个月，这个月我一直在思考一个问题 —— 「人与 Agent 的协作系统究竟长什么样子？」

具体到实践中的痛点是，怎样能构建一个 Agent 持久自主干活的系统。让人不是其中的卡点。这里面其实包含了三种核心场景，

• 周期任务，典型如监控系统，周期性的去执行某个预设的探索性任务，包括小龙虾的 heartbeat 机制。
• 事件任务，通过外部事件驱动，比如以某种 webhook 的形式，例如 github 出现一条 issue，就给 Agent 发送一条 提醒query。
• 长程任务，1)需求规模很大的任务，比如你希望Agent 实现几万字的 PRD 对应的需求功能、你希望完成几千家的商业分析。2)也可能是答案未知的探索型任务 e.g auto research。

这个过程中模型能力快速变强，一定会吃掉越来越多的 harness脚手架，那这个过程中，究竟什么是不变的东西？什么是产品应该去做的事？

我现在有了一个初步答案，尝试做了一个产品形态 - MyAgents 任务中心

• 人类去思考并记录想法，想法在与 AI 讨论中生长为任务
• Agent系统 负责贯彻人类意图执行任务

并且对应开源了一套与 AI 深度对齐目标并执行长程任务的 Skill

• /task-alignment：AI 引导讨论，梳理思路对齐目标，创建 Task
• /task-implement：由 AI 作为人类代理，长时间执行完成 Task

接下来我想详细聊聊为什么？那先从让我感到别扭的两类产品设计说起

第一类：把 Agent 套进看板里

界面长这样——左到右五列：Backlog / Todo / In Progress / In Review / Done。每张卡片是一个 issue，用户拖着卡片在列之间走。区别仅仅在于卡片背后是 Agent 在干活，不是人。

我不是反对看板这个工具本身 —— 看板（Kanban）被发明出来已经 80 多年，从丰田车间到现代软件团队都在用，它解决的是多人异步协作下任务过程管理问题，通过原子化角度拆解任务，不同人来负子任务，通过看板来了解整个项目的进展过程。

但到了 AI Agent 这里，这两个前提都消失了：

需求执行在更多的闭环化，弱化人与人的协作，人与Agent 协作也不是在宏观上拆分任务，而是 Agent 在一个 session 会话 Context 里进行调度子 Agent 执行，这些并不需要被记录在宏观的任务系统里，因为这些动态的小颗粒度的任务就是一些 session 里的 todos，人不在意。

而同样任务在每个「状态」下的停留的时间从几天压缩到几分钟到几小时 —— AI 接到任务就开始跑，跑完直接进 review，直接完成

这种情况下展示 5 列的看板有什么意义呢？你回过神任务已经结束了。

因此这里的关键点只有两个 —— 1）起点：人的意图；2）结果：AI 的产出。
中间的过程管理，只会越来越不需要人的参与，自然也就不需要看板的”列”。

第二类：给 Agent 拉群，所谓人格化的多 Agent 模式

各种”Agent 智囊团”、”三省六部”、”多 Agent 协作” —— 产品 UI 长得要么是微信群，要么是Channel 群聊，想要凸显几个人格各异的 Agent 在群里你一言我一语讨论问题，最后给用户一个结论。

每次看到让多个 Agent 在群聊里互相讨论这件事，我每次看都觉得是产品经理在演戏。因为这些 Agent 之间根本不需要 IM。

IM 这种通信形态是为人类设计的 —— 人类期望平等、需要表达情绪、需要异步。所以 IM 的形态是「群、消息流、表情包、@ 提醒」。

而 Agent 之间，没有任何一个特征成立。Agent 不会下班，没有平等关系，不会闹情绪。你硬把它们放进群里互相 @，实际上是把 Agent 拟人化包装一下让中登们获得一些掌控感。

Agent 的边界是 context 的边界，不是人格的边界。

Agent 不需要名字，不需要职业，不需要群聊。它只需要：一个清晰的目标、一切相关的 context、一份清晰的结果交付。

那 Agents 如何协作？所谓的 multi-Agents 可以划分为两类，

同类 Context 任务（比如研发），Agents 工作的正确形态是树 —— 主 Agent 拆解任务，派遣子 Agent 在独立 context 里完成有边界的工作，子 Agent 返回结果，主 Agent 综合判断。decompose, delegate, synthesize. 这种设计的关键是解决 Context 效率的问题。

不同类 Context 的协作（例如研发 vs 销售），的正确形态是异步的 Context 交接，而不是 IM 聊天。本次先不展开，这个话题稍后我会再发一篇文章。

到这里我得叠一个甲：

1. 我反对的是”让 Agent 在群聊里互相聊天”、以及用人类分工来限制 Agent 边界的行为。
2. 我不反对”用 IM 作为人触达 Agent 的入口” —— 比如飞书机器人。前者是一种低效的形式主义，他当然能跑通，但效率低下；后者则是人类向 Agent 传递意图的天然入口。这两件事是完全不同的。

上述的两种产品探索都在做一件事：用人类的协作范式硬套给 Agent。强行把 Agent 装进看板和群聊里，是用上一个时代的协作形态约束下一个时代的智能体。

那么我认为的正解是什么？

要回归这个场景的第一性：人的注意力

Agent系统 可以并行几百上千个、可以 7x24 小时运转，他是一套无限系统。

而人之所以为人，恰恰是因为人的有限性，人一天只有 24 小时，人的每一个决策都要付出代价，我们的一切系统、组织、工具都是在进行信息降噪，将我们宝贵的注意力用于关键的决策。

因此回顾历史你会发现，AI Agent 系统的成功案例都有一个主线，人的注意力层级在不断上移！

我们回头看一下这轮 Coding Agent 的发展史：

• Cursor vs VSCode：Cursor 精妙的 tab AI 补全，让用户的注意力从代码行级别，抬升到了函数级。你在函数级别和 AI 对齐意图。
• Cursor Agent vs tab 补全：这是让更多人用 Cursor 的起点，第一次发现 AI 居然可以自己调用工具连续工作，直接完成一个功能需求，而我们在 Chat 对话框里指导 AI 工作，在必要时才用编辑器看看或修改代码。
• Claude Code vs Cursor：CC 是对模型能力的押注，并在产品形态上直接放弃编辑器。迫使用户注意力抬升到了 chat 级，你在自然语言对话里讲清楚要什么。随着模型一次一次跃升，过去会额外用编辑器检验代码的人也自然而然放弃了这个动作。****

那下一站会是什么？从 chat 会话抬升到任务级，核心关键词「长程任务」

如同我上篇介绍 vibe coding 的文档里所说，在做 coding 的过程中，从早期一来一回的与 AI 沟通任务执行并审阅，我的注意力就成了复杂任务的决策瓶颈。

而我想要的是：把一个事情的来龙去脉、目标、验收标准全部交代清楚，然后让 AI 自己去跑几小时，跑完了告诉我结果，中间的过程我完全不需要看。

这就是「长程任务」。这就是我说的”任务级”。

而当注意力来到任务级，那么 AI 工具的产品形态就必然会从「对话框」演化成「任务中心」。

模型能力与 Agent Runtime 持续协同进化，让任务执行的成功率不断飙升，「任务执行」占据的人类注意力越来越小。这种情况下，「长程任务」究竟需要给 AI 什么？

我的答案：人类意图 —— 我的目标、我如何定义好的结果。

我理想的任务中心，人的注意力应该收敛到两件事 —— 管理想法，确认结果。中间的执行过程，全部交给 AI。

我设计了一套系统与一组 Skill 来实现这件事。

先说系统，我在 MyAgents 设计了一个新的「任务中心」，它的核心即「想法管理」与「任务执行」。

• 左栏：想法池，
  所有任务的起点，用户可以随时记录自己的想法
• 右栏：任务卡片，
  单次执行、定时周期执行的各类任务

注意，这个产品里没有任何复杂的 workflow 配置。没有自定义状态、没有自动化规则、没有视图切换。因为这些东西都是在解决”人维护流程”的问题——而我已经把这件事彻底交给 AI 了。

想法管理：人类意图的收集与上下文记录

想法池放在最显眼的位置，因为我认为想法是所有产品对任务系统里最被低估的环节。

绝大多数 To-Do / GTD / 任务管理产品，都把想法当成一个”漏斗的入口” —— 所有进来的想法都应该被推向行动，他是在让人浓缩出行动，自己来完成执行。

但 Agent 系统的构建，应该是一个成长型系统，他应该包含你的思考过程而非全是最终决策的行动。

这些被记录下来的想法，他的归宿是多样的：

• 直接派发为任务
  —— 我已经想得非常清楚，直接让 AI 照着想法开干，想法就是 Prompt
• 与 AI 讨论后凝结成任务
  —— 在讨论中不断澄清想法，AI 引导我把它想得更深刻、更清晰，最终变成一份完整的任务定义
• 与 AI 讨论本身就是产出
  —— 讨论之后想法被想清楚了、得到了答案、或者被我自己否决了。这张想法卡停留在想法池里不动，这也是合法的归宿

第三条尤其重要。多数 GTD 产品都在做”想法漏斗”，强迫每个想法变成行动。我反过来 —— 讨论本身就是产出，拒绝也是产出。一个想法被认真讨论过然后被搁置，比一个想法被仓促推进做出一坨没人用的东西，价值高得多。

任务执行：AI 与我对齐目标，并进行长程执行

进入到执行环节，关键是我写的两个 Skill，task-alignment 与 task-implement：

• 前者是 AI 如何与人类对齐意图，获取任务目标与评价标准
• 后者是替人类监工与执行，我称之为 User Proxy Agent

而这套设计里我觉得最有趣的部分，是通过 task-alignment，我让一个想法变成了一份标准化契约。一份不再依赖 session 上下文，可以任意 Agent 独立执行的契约

而这份契约的物理形态，是四个 markdown 文件：

文件

角色

谁来写
alignment.md
决策记录、用户强调点、open questions

人 + AI 对话共建
task.md
北极星 —— 目标、范围、约束、非目标

人 + AI 对话共建
verify.md
验收契约 —— 三层（自动 / 自查 / 集成）

人 + AI 对话共建
progress.md
执行流水 —— Plan + Change Log

AI 独立维护

而生成这份契约的方式，不是填表单，是和 AI 进行一次完整的对话。task-alignment 这个 skill 会和你一起把想法聊清楚，并输出前三份文档。

「Documents are crystallization of dialogue, not a template with blanks filled in.」

verify.md：长程任务真正的瓶颈

四份文档里我最想单独拎出来讲的，是 verify.md。

绝大多数人讨论”长程任务”的时候，焦点都在「目标定义」 —— 怎么把任务讲清楚。但长程任务真正的瓶颈不是执行，是验收。

让 AI 干两个小时不难，难的是：它怎么知道自己干完了？干完得对不对？

如果你不能把”什么叫做完了”讲清楚，那 AI 跑两小时跑十小时跑一百小时都没用 —— 它只会停在某个看似合理的地方说”我做完了”，然后你打开一看一坨答辩。

没有 verify.md，AI 干一万小时也只是耍流氓。

progress.md：AI 自己写的执行流水

我想专门解释一下 progress.md，因为它正是前面反看板那段我说的”AI 写的日志”。

它的结构很简单他就是一份仅有任务状态信息的空文档。它由 Agent 使用 skill(task-implement) 在执行过程中自己更新 —— 执行到哪一步、遇到什么、做了什么决策、解决了什么问题，全部写进去。

这就是为什么我说不需要看板：进度状态不重要，有价值的信息是 AI 自己写的一段叙事。用户随时打开任务卡片就能看到，比看板的”列”细致一百倍，而且零人力维护。

契约准备好之后，谁来执行？

我把执行端也封装成了一个 skill，叫 /task-implement。但它远不只是个”执行器”。它的真实定位是 —— 你不在场时的代理人，UserProxy Agent。

这个定位很关键。task-implement 不是”按指令操作的工具”，是”带着你的标准去工作的代理人”。它做执行，更做判断。Guided by alignment.md。

它的核心纪律有几条：

第一，目标是不变量，计划是可变的。

The goal in task.md is the invariant. The plan is flexible.

它会按 progress.md 的初始计划开始跑，但执行过程中如果发现某一步不对、某个依赖不在了、某个文件被重构了 —— 它会停下来，把发现写进 Change Log，找你 re-align。

第二，遇到契约和现实矛盾，停下来，不要瞎搞。

如果 task.md 和实际情况冲突了，它不会硬着头皮往下做。它会停止执行，写下”这里和契约不一致”，然后等你拍板。这是代理人和工具的本质区别 —— 代理人懂得在什么时候问，工具只会闷头干。

第三，验收必须 independent。

自己写的代码自己 review 不靠谱（这一点我在上一篇 Cross Code Review 那篇讲过）。task-implement 跑完之后，会强制开一个新的 context、派一个独立子 Agent 去跑 verify.md 里的所有项。它自己绝不验证自己。

整个过程里，AI 在替你工作、替你思考、替你判断。而你不需要在场。

这套设计里我自己最喜欢的一个机制，是 task-alignment 里的渐进式决策。

绝大多数任务管理产品都要求用户在一开始就做一个决策：「我现在是要发起一个新任务、还是只是想聊一下？」

但用户经常不知道。一个想法刚冒出来的时候，你也不知道它该被聊掉还是该被执行。强迫用户在第一秒做决策，本身就是一种不友好。

我的方案是 —— 默认聊。与 AI 聊着聊着，这个想法的 scope 长大到 AI 觉得”这件事值得开个独立任务了”，AI 会主动提议：

「这个聊得已经比一开始大了 —— 我们要不要把目前的对齐固化成一个任务，开新 session 让它独立跑？这样你可以离开，不用盯着。」

你同意 → AI 把对话凝结成那四份文档 → 派发到独立 session → 你回到任务中心看着卡片状态走就行。

任务中心不是重型流程。它是一个会自己生长的系统。

这套东西我已经做出来了

1. 两个核心 skill 已经开源在 Github 仓库

2. MyAgents 任务中心则更是把这套抽象做成了完整的产品体验：

使用流程如此简单：

• 倒想法：任何冒出来的想法都先扔进想法池，不评估、不筛选
• 聊想法：觉得某个想法该被推进，点 “AI 讨论” 按钮，和 AI 把它聊清楚
• 派任务：聊清楚后凝结成四份文档，派到独立 session 让 UserProxy Agent 去执行
• 看结果：任务跑完了打开看交付物，确认就 merge，不满意就让 AI 接着改

这四步之后，人的注意力被收敛到了想法的起点和结果的终点。中间的全部执行过程，被浓缩进每一张任务卡背后的 session 里。你想看可以打开看，不想看就不用看。

我在上一篇文章里说过：超级个体是那些能够「定义出好问题」、操控 AI「规模化执行其意志」、最终捕获价值的人。

这一个月做完任务中心之后，我想把那句话再具体一点：

超级个体是一个「人 + 想法与目标 + Agent」的系统。
超级个体是那些能够构建一套系统，一套能管理好你的想法对齐你的目标，由Agent 7×24 小时贯彻你的意志的系统。

模型还会越来越强，长程任务执行成功率会越来越高。那些能够率先把自己的工作流重构成”管理目标与想法 + Agent执行”形态的人，会是第一批起飞的人 —— 因为他们的注意力效率会和别人拉开数量级的差距。

而如果你总是热衷于把精力放在摆弄看板和群聊 Cosplay，你就还在用上一个时代的工具，做下一个时代的事。

如果你也想体验这套任务中心，欢迎来用：

• 官网：https://myagents.io
• GitHub：https://github.com/hAcKlyc/MyAgents
• 开源 skill：https://github.com/hAcKlyc/MyAgents_skills

如果你看到这里，欢迎关注一下公众号「Ethan的探索之路」。我会持续分享 AI native 的工作生活方法，探索人 + AI 的天花板究竟在哪里。

Author: Ethan L
Co-Author: Mino powered by Claude Opus4.7
配图: ChatGPT image-2

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。