最近，Agent 类开源项目又火了一个。

项目名叫 Craft Agents。

它不是又一个“给大模型套壳的聊天工具”，也不是简单把几个 MCP 工具接起来，而是试图解决一个更具体的问题：

当 Agent 真正进入日常工作流后，我们到底该怎么管理它、调度它、连接工具、控制权限，并让它持续执行任务？

这也是 Craft Agents 值得关注的地方。

过去很多人用 Agent，体验大概是这样的：

打开一个终端，输入一段 Prompt，等模型调用工具、改代码、读文件、跑命令。

能用，但很“工程师自娱自乐”。

一旦任务变多，就会出现几个问题：

• 多个 Agent 会话怎么管理？
• 哪个任务正在跑，哪个任务需要确认？
• Agent 能不能连接 Gmail、Slack、Linear、GitHub、Notion？
• 权限怎么控制，哪些能只读，哪些必须人工确认？
• 长任务能不能后台跑？
• 能不能像管理工单一样管理 Agent 任务？

Craft Agents 的出现，某种意义上说明了一件事：

Agent 工具正在从 CLI 阶段，进入桌面工作台阶段。

阅读目录

1. Craft Agents 到底是什么？
2. 为什么它会突然火起来？
3. 它解决的不是“聊天”，而是 Agent 工作流管理
4. Craft Agents 的核心能力拆解
5. 它和 Claude Code、MCP、普通 AI 聊天工具有什么区别？
6. 从架构角度看，Craft Agents 做对了什么？
7. 对测试开发、自动化测试、研发效能有什么启发？
8. 这类 Agent 工具的真实风险在哪里？
9. 写在最后：Agent 的下一站，是可控的工程系统

一、Craft Agents 到底是什么？

Craft Agents 是一个开源的 Agent 工作台工具。

从官方 README 的描述来看，它的目标不是单纯做一个聊天界面，而是帮助用户更高效地与 Agent 协作，包括多任务处理、连接外部 API 或服务、共享会话，以及一种更偏“文档中心”的工作流。([GitHub][1])

官方也明确提到，它同时使用了 Claude Agent SDK 和 Pi SDK，并且强调自己是基于 Agent Native software 理念构建的工具。([GitHub][1])

简单理解：

Craft Agents = 桌面端 Agent 工作台 + 多模型连接 + MCP/API/本地文件源接入 + 会话管理 + 权限控制 + 自动化任务。

它更像是一个面向 Agent 的“任务操作系统”。

不是让你问一句、答一句，而是让你把 Agent 当成一个可以持续工作的“执行单元”。

二、为什么它会突然火起来？

Craft Agents 的爆火，并不只是因为它开源了。

真正的原因是：它踩中了 Agent 工具从 Demo 走向生产力工具的关键痛点。

过去一年，很多 Agent 工具都在强调：

• 会调用工具
• 会读文件
• 会写代码
• 会跑命令
• 会调用 MCP
• 会接入浏览器
• 会多步推理

但很多工具的问题也很明显：

能力很强，但工作流很散。

你让 Agent 改一个文件，它可以； 你让 Agent 接一个 API，它也可以； 但你让它同时管理多个任务、多个来源、多个权限状态、多个执行进度，就开始变得混乱。

Craft Agents 的重点不在于“让模型更聪明”，而在于：

给 Agent 一个更像工作台的运行环境。

这也是为什么它能在 GitHub 上快速获得关注。当前仓库页面显示，Craft Agents 已有 5.8k Star 和 779 Fork。([GitHub][1])

三、它解决的不是“聊天”，而是 Agent 工作流管理

很多人判断一个 Agent 工具，只看它能不能回答问题。

但真正进入工程场景后，更重要的问题是：

Agent 能不能被管理。

一个可落地的 Agent 工具，至少要解决 5 件事：

Craft Agents 的设计思路很清楚：

不要只把 Agent 当成聊天对象，而要把 Agent 当成工作流节点。

这对研发、测试、运营、文档、项目管理都有启发。

四、Craft Agents 的核心能力拆解

根据项目 README，Craft Agents 提供了不少关键功能，包括多会话收件箱、多模型连接、Craft MCP 集成、Sources、权限模式、后台任务、动态状态系统、多文件 Diff、Skills、文件附件和自动化能力等。([GitHub][1])

可以拆成几个核心模块来看。

1. Multi-Session Inbox：Agent 任务也需要“收件箱”

Craft Agents 提供了类似 Inbox 的多会话管理能力。

这点很关键。

因为 Agent 一旦真的进入工作流，它不再只是一个聊天窗口，而会变成多个并行任务：

• 一个 Agent 在整理需求文档
• 一个 Agent 在分析日志
• 一个 Agent 在改自动化脚本
• 一个 Agent 在接 Slack / Gmail 数据源
• 一个 Agent 在跑后台任务

如果没有统一管理，很快就会失控。

Craft Agents 把 Session 设计成可以管理状态的任务单元，比如 Todo、In Progress、Needs Review、Done 这类流程状态。README 中也提到其 Session Management 支持 Inbox/Archive、Flagging、Status Workflow、Session Persistence 等能力。([GitHub][1])

这意味着 Agent 工具开始具备一点“轻量任务管理系统”的味道。

2. Sources：Agent 不只是读文件，而是连接真实系统

Craft Agents 的一个重点能力是 Sources。

官方说明里，Sources 可以连接 MCP Servers、REST APIs 和本地文件系统，示例包括 Craft、Linear、GitHub、Notion、Google、Slack、Microsoft、本地文件、Obsidian vault、Git 仓库等。([GitHub][1])

这意味着 Agent 可以从“只读你上传的文件”，走向“连接真实业务系统”。

这件事的意义很大。

因为企业里的很多工作，不是发生在一个文件里，而是分散在：

• 邮件
• 日历
• 工单
• 代码仓库
• 文档系统
• IM 工具
• 数据库
• 本地项目目录
• 自动化测试平台

Agent 想真正工作，就必须能进入这些系统。

Craft Agents 的 Sources 设计，本质上是在做一件事：

把 Agent 的上下文边界，从聊天窗口扩展到真实工作环境。

3. Permission Modes：Agent 能力越强，越需要权限边界

Agent 工具最容易被忽略的一个问题是权限。

很多人刚开始用 Agent 时，会觉得：

“直接让它自动执行不就好了？”

但在真实工程环境里，这很危险。

比如 Agent 可能会：

• 删除文件
• 修改配置
• 执行命令
• 调接口
• 改数据库
• 推送代码
• 操作线上系统

所以，一个成熟的 Agent 工具必须有权限分层。

Craft Agents 提供了三种权限模式：

README 中明确列出了 safe、ask、allow-all 三种模式，并说明 safe 是只读、ask 需要审批、allow-all 自动批准。([GitHub][1])

这才是 Agent 工程化落地的关键。

不是 Agent 越自动越好，而是：

该自动的自动，该确认的确认，该隔离的隔离。

4. Skills：让 Agent 从“通用助手”变成“岗位助手”

Craft Agents 也支持 Skills。

官方说明中，Skills 是存储在 workspace 里的专用 Agent instructions。([GitHub][1])

这点和当前 Agent 工具的发展方向高度一致。

因为通用 Prompt 很难解决复杂岗位问题。

真正有价值的是把组织经验沉淀成可复用技能，比如：

• 需求评审 Skill
• 接口测试用例生成 Skill
• 性能瓶颈分析 Skill
• 日志排查 Skill
• Playwright 脚本生成 Skill
• 测试报告总结 Skill
• 缺陷复盘 Skill
• 自动化框架改造 Skill

这类 Skill 的意义，不是简单“写一段提示词”。

而是把团队里的经验、约束、流程、模板和工具调用方式封装起来。

以后新人不用重新摸索，Agent 也不用每次从零理解。

5. Automations：Agent 开始进入事件驱动阶段

Craft Agents 的 README 提到 Automations：可以基于标签变化、时间计划、工具使用等事件创建 Agent sessions。([GitHub][1])

这其实很重要。

因为 Agent 的下一步，不只是“我问它答”，而是：

当某个事件发生时，Agent 自动进入工作流。

比如测试场景里：

• 新需求进入评审状态，自动生成测试点
• PR 创建后，自动分析变更影响范围
• CI 失败后，自动读取日志并归因
• 线上告警后，自动生成初步排查报告
• 每天定时汇总缺陷趋势
• 每周自动整理测试覆盖率变化

这就是从 Chatbot 到 Agent Workflow 的变化。

五、它和 Claude Code、MCP、普通 AI 聊天工具有什么区别？

可以用一张表理解。

所以 Craft Agents 不是简单替代 Claude Code，也不是替代 MCP。

更准确地说：

MCP 更像连接协议，Claude Code 更像代码执行代理，Craft Agents 更像 Agent 工作台。

它把模型、工具、数据源、权限、会话和自动化流程放在一个桌面应用里管理。

六、从架构角度看，Craft Agents 做对了什么？

架构里，最值得关注的不是某一个功能，而是它的分层方式：

1. UI 层：让 Agent 工作可视化
2. Session 层：让任务可管理
3. Agent 层：让模型可替换
4. Sources 层：让上下文可扩展
5. Permission 层：让执行可控
6. Skills 层：让经验可复用
7. Automation 层：让流程可触发

这比单纯做一个聊天框更接近工程化。

七、对测试开发、自动化测试、研发效能有什么启发？

Craft Agents 对测试开发从业者很有参考价值。

因为测试工作天然就是“多系统、多数据、多流程、多角色”的工作。

一个测试同学每天可能要接触：

• 需求文档
• 接口文档
• 代码仓库
• 测试用例
• 自动化脚本
• CI/CD 日志
• 缺陷平台
• 线上监控
• 测试报告
• 项目群消息

这些信息分散在不同平台里。

如果 Agent 只会聊天，价值有限。

但如果 Agent 能连接这些系统，并按权限规则执行任务，它就可能真正进入测试工作流。

场景 1：需求进入评审，自动生成测试分析

这类场景最适合 Agent。

因为它不是替代测试工程师，而是把重复的信息整理工作提前完成。

测试工程师真正要做的是判断：

• 哪些风险最关键？
• 哪些历史问题需要回归？
• 哪些场景不能漏？
• 哪些接口需要重点验证？
• 哪些用例必须自动化？

场景 2：CI 失败后，自动做初步归因

这类工作不是“很难”，但很耗时间。

Agent 的价值在于：

先把 60% 的排查路径跑完，让人直接看结论和证据。

场景 3：自动化测试脚本维护

Agent 可以结合：

• Git 仓库
• Playwright / Selenium 脚本
• 页面截图
• 失败日志
• DOM 变化
• 测试报告

自动分析：

• 是定位器失效？
• 是等待策略不合理？
• 是环境响应变慢？
• 是断言逻辑过强？
• 是页面交互流程变化？

这比单纯让 AI “帮我写自动化脚本”更有价值。

真正难的不是写第一版脚本，而是长期维护。

八、这类 Agent 工具的真实风险在哪里？

Craft Agents 这类工具很有想象力，但不能神化。

它进入工程环境后，至少有 4 类风险要注意。

1. 权限风险

Agent 一旦能调用工具、执行命令、访问外部系统，就必须严格控制权限。

尤其是：

• 写文件
• 删除文件
• 执行 shell
• 调生产接口
• 访问数据库
• 读取敏感文档
• 连接企业 IM 和邮箱

Craft Agents 的权限模式是一个好设计，但最终是否安全，还取决于用户怎么配置。

Agent 工具不是不能自动化，而是不能无边界自动化。

2. 上下文污染风险

Agent 接入的数据源越多，越容易出现上下文混乱。

比如：

• 读错文档版本
• 引用过期接口说明
• 混淆测试环境和生产环境
• 把历史需求当成当前需求
• 把不同项目的规则串在一起

所以企业落地 Agent 时，知识源治理非常关键。

不是把所有资料塞给 Agent 就行，而是要处理：

• 数据源分级
• 文档版本
• 权限边界
• 更新周期
• 引用可追溯
• 输出可验证

3. 自动执行风险

Auto 模式很爽，但风险也最高。

建议真实团队使用时，至少遵守一个原则：

读操作可以宽，写操作要严；低风险可以自动，高风险必须确认。

比如：

4. 评估风险

Agent 输出看起来很完整，不代表它是对的。

测试团队尤其要注意：

• 生成的测试点是否遗漏核心风险？
• 自动化脚本是否可长期维护？
• 日志归因是否有证据链？
• 生成的报告是否可复现？
• Agent 是否引用了错误数据源？
• 任务是否真的执行成功？

所以 Agent 进入测试体系后，不能只看“能不能生成”，还要建立评估机制。

九、Craft Agents 给行业释放的信号

Craft Agents 的走红，本质上说明了一个趋势：

Agent 工具正在从单点能力，走向工作流系统。

过去我们关注的是：

• 模型能不能写代码？
• Agent 能不能调用工具？
• MCP 能不能接入更多服务？
• Claude Code / Codex 能不能自动改项目？

接下来更重要的问题会变成：

• Agent 会话怎么管理？
• Agent 任务怎么编排？
• Agent 权限怎么控制？
• Agent 输出怎么审计？
• Agent 技能怎么复用？
• Agent 怎么接入企业真实系统？
• Agent 怎么和人的工作流协同？

这才是 Agent 工程化的主战场。

十、写在最后：Agent 的下一站，是可控的工程系统

Craft Agents 不是第一个 Agent 工具，也不会是最后一个。

但它值得关注的地方在于：

它没有只停留在“模型能力展示”，而是开始处理 Agent 真正落地时绕不开的问题：

任务、会话、权限、工具、数据源、技能、自动化。

这说明 Agent 正在进入一个新阶段。

不是谁 Prompt 写得更花，谁就更强； 不是谁接的 MCP 更多，谁就更强； 不是谁能自动跑命令，谁就更强。

真正能落地的 Agent 系统，一定要满足三个条件：

1. 能连接真实工作环境
2. 能沉淀团队经验和流程
3. 能在权限边界内稳定执行任务

对测试开发同学来说，这个趋势尤其值得重视。

未来的测试能力，不只是会写用例、会写脚本、会搭平台。

更重要的是：

你能不能把测试流程、质量规则、自动化能力和 Agent 工作流结合起来。

因为 AI 不会只改变开发，也会重构测试。

而 Craft Agents 这类工具，正是这个变化的一个早期信号。