AI Agent 设计改造 #1：Devin 编程 Agent 的任务状态可视化

一、今日选择的 Agent 产品

产品：Devin by Cognition 是什么：Devin 是全球首个 AI 软件工程师 Agent。它不像 Copilot 那样在你写代码时补全——而是你给它一个任务描述（如「帮我加一个用户登录功能」），它在云端独立环境里编写代码、运行测试、修复 bug，完成后把代码交给你审查。

为什么今天值得分析：Devin 正在从单人开发者工具向团队协作平台转型。2026 年 6 月的产品更新引入了「Parallel Cloud Agents」——允许多个 Devin 实例同时处理不同任务。这个功能让产品复杂度急剧上升——单个 Agent 已经够难跟踪了，多个 Agent 同时跑的时候，用户完全不知道谁在做什么。

热度依据：

• Hacker News 多周首页讨论，评分 4.2/5
• GitHub 相关仓库 Star 增长稳定
• 多家科技媒体报道其从「单人工具」向「团队平台」转型
• 社区讨论焦点集中在「Agent 任务可见性」问题

二、功能场景

用户是谁：全栈开发者，正在做一个 Next.js 项目，同时跑 3 个 Devin 实例——一个改后端 API、一个加前端组件、一个修 bug。

用户想完成什么：在下午 4 点前确认三个任务都已完成且代码质量可接受，然后合并到主分支。

当前步骤：

1. 在 Devin 面板创建 3 个任务
2. 每个 Agent 独立开始工作
3. 用户需要分别点进每个 Agent 的窗口看进展
4. 发现一个 Agent 卡住了，手动介入给指令
5. 另一个 Agent 完成了但代码有问题，需要 review
6. 在 3 个窗口来回切换，脑力消耗大

为什么这个场景重要：这是多 Agent 协作的典型场景。随着 Agent 能力增强，一个开发者同时管理多个 Agent 将成为常态。如果管理体验跟不上，Agent 能力再强也用不好。

三、当前体验痛点

痛点 1：任务执行过程完全不透明

Agent 在工作时，用户只看到一个模糊的「Running」状态和一个滚动日志。但日志是机器日志风格，不是给人读的——用户不知道 Agent 当前在做什么、为什么做这个、预计还要多久。

影响：用户无法规划自己的时间。如果 Agent 再有 2 分钟就完成了，用户会等。但如果 Agent 已经被一个不可解的错误卡住了 10 分钟，用户还在傻等。

设计缺陷：缺少面向人的「任务阶段分解」。Agent 的内部状态机没有映射到用户可理解的工作流上。

痛点 2：多 Agent 并行时的信息过载

3 个 Agent 同时跑，用户要在 3 个窗口间来回切换。无法快速对比三个 Agent 的进度、遇到的问题、预计完成时间。

影响：管理 1 个 Agent 时还好，管理 3 个时认知负荷爆表。这直接影响用户是否愿意使用多 Agent 功能。

设计缺陷：缺少「多 Agent 仪表盘」。当前设计是为单 Agent 场景做的，多 Agent 只是简单复制了 3 个单 Agent 窗口。

痛点 3：Agent 失败时的信息不完整

Agent 遇到错误停止时，信息散落在日志中。用户需要手动翻阅几百行日志才能定位问题。

影响：用户介入效率极低。本来 Agent 节省的时间，在排查问题时又还回去了。

设计缺陷：缺少结构化的「失败摘要」。Agent 知道自己为什么失败了（调用了什么、返回了什么错误），但没有把信息组织成用户可以快速理解的诊断报告。

四、设计改造方向

聚焦：多 Agent 并行任务看板 + 单 Agent 任务阶段可视化

具体改造：

• 一个「Agent 任务看板」替代当前的多个独立窗口——所有并行 Agent 以卡片形式横向排列，实时显示任务阶段、进度、当前状态
• 每个 Agent 卡片内引入「任务阶段指示器」——展示 Agent 当前在哪个阶段（理解需求 → 编写代码 → 运行测试 → 修复 → 完成），每个阶段有预估时间
• 失败时自动生成「故障摘要卡」——不用看日志就能理解：调用了什么、失败原因、下一步建议

五、设计 Prompt（可直接复制给设计专家 Agent）

---

📋 设计任务：Devin 多 Agent 任务看板

产品背景：Devin 是 AI 编程 Agent，能在云端独立完成编码任务。用户创建任务后，Agent 在后台运行，用户可以查看进度。最近推出了多 Agent 并行功能，但体验仍在单 Agent 设计上。

用户场景：全栈开发者同时管理 3 个 Agent 实例，需要快速了解每个 Agent 的进度、发现问题、介入处理。

当前痛点：

1. Agent 任务进度不透明——只能看到「Running」状态和机器日志
2. 多 Agent 并行时需在多个窗口间来回切换，认知负荷高
3. 失败时信息散落在日志中，排查效率低

设计目标：设计一个「多 Agent 任务看板」Web 页面，让用户在一个视图中管理所有并行 Agent。

需要产出：

• 一个完整的 Web 页面（HTML/CSS/JS），使用 React + Tailwind CSS 风格
• 包含多 Agent 卡片视图（至少 3 张卡片演示不同状态）
• 每张卡片包含：任务名称、当前阶段指示器、进度百分比、最近操作摘要、预计剩余时间
• 失败状态的 Agent 卡片要有醒目的「故障摘要」区域
• 支持卡片展开查看详细日志（可折叠）
• 顶部有一个全局统计条：运行中 / 已完成 / 失败的数量

视觉风格：深色主题（developer tool 风格），代码编辑器质感。参考 Linear / Vercel 设计语言。使用 monospace 字体做代码块，卡片用微妙边框和悬停效果。

信息架构：

• 顶部栏：全局统计 + 筛选（全部 / 运行中 / 已完成 / 失败）
• 主区域：Agent 卡片网格（3 列）
• 单张卡片：标题 → 阶段指示器 → 进度条 → 操作摘要 → 展开按钮

交互状态：

• 默认：卡片并列展示，显示摘要信息
• 展开：点击卡片展开详细日志和文件变更清单
• 加载：新任务创建时卡片有入场动画
• 失败：卡片变为红色边框，故障摘要自动展示
• 完成：卡片变为绿色边框，显示「Review Changes」按钮

输出格式：自包含 HTML 文件，可直接在浏览器打开。

六、设计方案

以下是根据上述 Prompt 直接产出的多 Agent 任务看板设计方案。

信息架构

页面采用「仪表盘」布局，从上到下分为三个区域：

顶部统计栏

• Agent 任务总数计数器
• 状态分类标签：全部 / 运行中（绿色）/ 已完成（蓝色）/ 失败（红色）
• 刷新按钮

主内容区：Agent 卡片网格

• 3 列自适应网格布局
• 每张卡片包含完整的任务信息

卡片结构（从上到下）：

1. 任务标题 + 状态标签
2. 阶段指示器（5 阶段进度条）
3. 进度百分比 + 耗时统计
4. 最近操作摘要（最后 3 条）
5. 展开按钮 → 详细日志 + 文件变更清单

视觉规范

• 底色：#0d1117（GitHub 暗色）
• 卡片背景：#161b22
• 运行中：绿色 #3fb950
• 失败：红色 #f85149
• 已完成：蓝色 #58a6ff
• 字体：Inter / JetBrains Mono
• 代码块：等宽字体 + 深色背景

交互流程

\n用户打开看板 → 看到 3 个 Agent 卡片 → 2 个 Running，1 个 Failed → 点击 Failed 卡片，展开故障摘要 → 看到「数据库连接超时，已重试 3 次」 → 点击「重新运行」按钮 → 卡片状态变为 Running → 5 分钟后所有卡片变绿 → 点击「Review Changes」查看 diff \n

关键设计决策

1. 用阶段指示器替代裸日志：将 Agent 内部状态机（5 阶段）映射为用户可视的进度条，降低理解成本
2. 横向卡片优于纵向列表：用户管理 3-5 个 Agent 时，卡片格式能同时展示所有关键信息，无需滚动
3. 「故障摘要」是独立组件：Agent 失败时自动提取关键信息（调用了什么 API、返回了什么错误、建议下一步），放在卡片顶部，用户不用翻日志
4. 展开日志是可选的深度模式：默认只展示摘要，满足 80% 场景；需要时可展开查看完整日志

产出物

完整的可交互 HTML 原型将在下一节提供。包含：

• 3 个 Agent 卡片（Running / Running / Failed 状态）
• 完整的阶段指示器动画
• 可展开的日志面板
• 全局统计栏
• 深色主题 + 代码编辑器风格