Agent 跑长任务失控，根本原因不是模型不够聪明，而是你没给它一个不会散架的工作结构。目标没锁死、任务没拆开、中途补的要求随手一丢——这三件事加在一起，就是大多数 Agent 任务最后一团乱麻的原因。
你可能有过这种体验：把一个复杂任务交给 Agent，开头几轮感觉很顺，它会读代码、跑命令、解释报错，像个靠谱的协作者。但跑着跑着就开始飘——顺手去优化跟任务无关的代码，把"修复启动问题"做成了"重构整个项目"，之前说过"不要动数据库"它也忘了。最后 diff 越来越大，你也搞不清它到底完成没有。
这不是模型的问题。长任务不是聊天，它需要运行结构。
/goal：目标没写清楚，Agent 不知道什么时候该停
很多人给 Agent 的任务是这样的："帮我把这个 Next.js 项目修好。"
这句话看起来清楚，其实太松了。能启动算修好？build 通过算修好？测试全绿算修好？你自己都没想清楚，Agent 当然会一路往前滚，直到你叫停。
更好的方式是把任务写成一个可验收的目标，带完成标准、带限制条件：
把这个 Next.js 项目从本地无法运行，推进到可以提交 PR。
完成标准：npm install 成功、build 通过、首页能打开、只修改必要文件、最后输出改动摘要。
限制：不改数据库 schema，不引入新的重量级依赖，不做无关重构，每次改动先验证再继续。
这才是 Agent 能拿着跑的目标。Hermes 的 /goal 命令做的就是这件事——给 Agent 设一个任务锚点，让它的每一步都知道自己在往哪儿走、走到哪里算结束。
Agent 长任务失控，很多时候不是因为它不知道怎么做，而是因为它不知道什么时候该停。你不给完成标准，它就会继续"顺手改"；不给限制，它就会自行扩大范围。
长任务还有个高频场景：你一开始没想全，跑到一半突然要补要求。
这时候很多人的本能反应是重新发一条大 prompt："重新调整一下，注意不要改数据库，移动端也要可用，另外最后给一版非技术摘要。"
问题在于，这种写法很容易让 Agent 误判——它可能觉得主任务变了，把新要求压过旧目标，或者在下一轮里只关注你刚说的内容，把之前的完成标准忘个干净。
更稳的方式是把补充要求写成独立的子约束，叠加在原目标上，而不是替换它。Hermes 的 /subgoal 就是干这个的：
主线没变，Agent 仍然在完成原来的目标，只是验收标准变严了。这比每次补要求都重新"教育"它一遍要可靠得多。
Kanban ：大任务必须拆，卡片必须小
如果目标解决的是"方向不丢"，那任务拆分解决的是"过程不糊"。
"帮我优化这个项目""帮我把这个产品跑起来"——这种任务人看了都要先拆，更别说 Agent。把大任务丢进去，它要么乱跑，要么在某一步卡住之后原地打转。
Multi-agent Kanban 的价值，不是 UI 上多了个看板。它真正的意义是把长任务拆成一组可领取、可重试、可验收的小卡片。每张卡只放一件事，每张卡都要有交付物，完成了能看到证据。
卡片要小到能交付。不要写"优化整个前端体验"，要写"检查首页移动端是否有文字重叠"。不要写"完善文档"，要写"在 README 添加本地启动步骤和环境变量说明"。
小任务有几个好处：容易验证（做完能看日志、截图、diff，不是一句"我已经优化好了"）；容易回滚（某张卡做坏了只处理这一块，不会污染整个任务）；还能并行，多个 Agent worker 可以同时处理不同卡片。
结果要有证据，不只是"任务完成"
判断一个 Agent 工作流好不好，不只看它有没有完成，更要看它有没有留下证据。
它运行了什么命令、命令结果是什么、改了哪些文件、为什么这么改、哪些地方没有验证、哪些风险还在——这些比"任务完成"四个字重要得多。Agent 会犯错，也会误判，甚至可能把失败说得很像成功。
所以长任务里，每个阶段都应该要求它交付可验证的东西。一个代码任务的交付物可以这样定义：改动文件列表、每个文件为什么改、执行过的验证命令及结果、未解决问题、是否需要人工确认。
这就是把 Agent 从"聊天对象"变成"工作流节点"。你不再只看它说了什么，而是看它留下了什么证据。
一个可以直接用的模板
如果要把复杂任务交给 Agent，建议不要从一句自然语言开始，直接用这个结构：
中途有新要求，就用 /subgoal 叠加，不要重写主任务。任务很大就拆 Kanban，每张卡一件事，每张卡有交付物。
Agent 能不能干活，模型能力当然重要。但当任务变长，真正决定结果的，往往是你有没有给它一个不会跑散的工作结构。目标锁定、任务拆开、证据留下——做到这三件事，Agent 才算真正可用，而不只是看起来很聪明。
AI 速览
