一个刚开源不久的 Agent 项目，GitHub 已收获 5.8k Star。它不是聊天套壳，也不是简单的 MCP 集成，而是一套真正的 Agent 工作台——解决多任务、多数据源、权限控制、后台执行等工程化难题。
最近，Agent 类开源项目又火了一个——Craft Agents。
项目地址：lukilabs/craft-agents-oss
一、Craft Agents 是什么？
Craft Agents 是一个开源的 Agent 工作台（Agent Workbench）。
它不是一个单纯的聊天界面，而是一套帮助用户高效与 Agent 协作的工具，包括：
- 多会话收件箱
- 多模型连接
- MCP / REST API / 本地文件接入
- 权限分级控制
- 后台任务
- 动态状态流转
- Skills 技能封装
- 自动化事件触发
官方明确提到，它同时使用了 Claude Agent SDK 和 Pi SDK，并基于 Agent Native software 理念构建。
简单理解：
Craft Agents = 桌面端 Agent 工作台 + 多模型连接 + 多数据源接入 + 会话管理 + 权限控制 + 自动化任务编排。
它不是让你问一句答一句，而是把 Agent 当作一个可以持续工作的 执行单元。
二、为什么它会突然火起来？
过去一年，很多 Agent 工具强调：
- 调用工具
- 读文件 / 写代码 / 跑命令
- 接入 MCP / 浏览器
- 多步推理
但它们普遍存在一个问题：能力很强，工作流很散。
让 Agent 改一个文件没问题，但让它同时管理多个任务、多个数据源、多个权限状态、多个执行进度，就开始混乱。
Craft Agents 的切入点不是让模型更聪明，而是给 Agent 一个更接近真实工作台的运行环境。
这正是它能在 GitHub 上快速冲到 5.8k Star、779 Fork 的原因。
三、它解决的不是“聊天”，而是 Agent 工作流管理
真正进入工程场景后，一个可落地的 Agent 工具至少要解决 5 个问题：
| 问题 | 传统聊天工具 | Craft Agents 工作台 |
|---|---|---|
| 多任务管理 | 多个窗口 / 上下文混乱 | 多 Session 收件箱 + 状态流转 |
| 工具接入 | 手工配置居多 | Sources（MCP / API / 本地文件） |
| 权限控制 | 容易“一把梭” | Explore / Ask / Auto 分级模式 |
| 长任务执行 | 容易中断 | Background Tasks |
| 过程追踪 | 看聊天记录 | Inbox / Archive / Flagging / 状态机 |
Craft Agents 的设计思路很清晰：不要只把 Agent 当成聊天对象，而是把它当作工作流节点。
四、核心能力拆解
1. Multi-Session Inbox：Agent 任务也需要“收件箱”
当 Agent 真正进入工作流，它不再是单个聊天窗口，而是多个并行任务：
- 整理需求文档
- 分析日志
- 修改自动化脚本
- 接入 Slack / Gmail
- 跑后台任务
Craft Agents 提供了类似 Inbox 的多会话管理，支持 Todo → In Progress → Needs Review → Done 的状态流转，并支持会话持久化、归档、标记。
这意味着 Agent 工具开始具备轻量级任务管理的味道。
2. Sources：从读文件到连接真实系统
Sources 可以连接：
- MCP Servers
- REST APIs
- 本地文件系统
示例包括：Craft、Linear、GitHub、Notion、Google、Slack、Microsoft、本地文件、Obsidian vault、Git 仓库等。
企业里的工作不是发生在一个文件里，而是分散在邮件、工单、代码仓库、文档、IM、CI/CD、自动化测试平台中。
Sources 的本质，是把 Agent 的上下文边界从聊天窗口扩展到真实工作环境。
3. Permission Modes：能力越强，越需要权限边界
Craft Agents 提供了三种权限模式：
| 模式 | 含义 | 适用场景 |
|---|---|---|
| Explore | 只读，阻止写操作 | 查资料、读代码、分析日志 |
| Ask to Edit | 修改前需要确认 | 改代码、改文档、调配置 |
| Auto | 自动批准命令 | 沙箱环境、低风险自动化 |
这才是 Agent 工程化落地的关键：该自动的自动，该确认的确认，该隔离的隔离。
4. Skills：让 Agent 从“通用助手”变成“岗位助手”
Skills 是存储在 workspace 里的专用 Agent instructions。
通用 Prompt 很难解决复杂岗位问题，真正有价值的是把组织经验沉淀成可复用技能，例如：
- 需求评审 Skill
- 接口测试用例生成 Skill
- 性能瓶颈分析 Skill
- Playwright 脚本生成 Skill
- 测试报告总结 Skill
5. Automations：Agent 开始进入事件驱动阶段
可以基于以下事件自动创建 Agent sessions：
- 标签变化
- 时间计划
- 工具使用
例如测试场景：
- 新需求进入评审 → 自动生成测试点
- PR 创建 → 自动分析变更影响范围
- CI 失败 → 自动读取日志并归因
- 线上告警 → 自动生成初步排查报告
这就是从 Chatbot → Agent Workflow 的变化。
五、与 Claude Code、MCP、普通聊天工具的区别
| 工具类型 | 主要解决什么 | 典型能力 | 局限 |
|---|---|---|---|
| 普通 AI 聊天工具 | 问答与内容生成 | 对话、总结、写作 | 工作流弱，工具接入有限 |
| Claude Code / Codex | 代码工程任务 | 读代码、改代码、跑命令 | 偏开发场景，任务管理较弱 |
| MCP | 工具协议与连接层 | 让模型调用外部工具 | 不是完整工作台 |
| Craft Agents | Agent 工作台 | 多会话、Sources、权限、后台、自动化 | 仍需验证复杂场景稳定性 |
Craft Agents 不是替代 MCP 或 Claude Code，而是把模型、工具、数据源、权限、会话和自动化放在一个桌面应用里统一管理。
六、架构视角：Craft Agents 做对了什么？
┌─────────────────────────────────────────┐
│ UI 层 │ ← 可视化 Agent 工作
├─────────────────────────────────────────┤
│ Session 层 │ ← 任务可管理
├─────────────────────────────────────────┤
│ Agent 层 │ ← 模型可替换
├─────────────────────────────────────────┤
│ Sources 层 │ ← 上下文可扩展
├─────────────────────────────────────────┤
│ Permission 层 │ ← 执行可控
├─────────────────────────────────────────┤
│ Skills 层 │ ← 经验可复用
├─────────────────────────────────────────┤
│ Automation 层 │ ← 流程可触发
└─────────────────────────────────────────┘
这套分层比单纯做一个聊天框更接近工程化系统。
七、对测试开发 / 自动化测试 / 研发效能的启发
测试工作天然就是 多系统、多数据、多流程、多角色 的。
如果 Agent 只会聊天，价值有限；但如果它能连接真实系统并按权限规则执行任务，就能真正进入测试工作流。
场景 1：需求评审 → 自动生成测试分析
Agent 读取需求文档 + 历史缺陷 + 接口文档 → 输出测试点、风险提示、回归建议。
测试工程师重点做判断，而不是重复整理。
场景 2：CI 失败 → 自动归因
Agent 读取失败日志 + 代码变更 + 环境配置 → 输出初步归因（定位器失效/等待策略/环境问题等）。
场景 3：自动化脚本维护
Agent 结合 Git 仓库 + 脚本 + 失败日志 + DOM 变化 → 分析是定位器失效、等待不合理、还是页面流程变化。
真正难的不是写第一版脚本，而是长期维护。
八、真实风险与挑战
1. 权限风险
- 写文件 / 删除文件 / 执行 shell / 调生产接口 / 访问数据库
必须严格执行 读写分离 + 确认机制。
2. 上下文污染风险
接入数据源越多，越容易读错版本、混淆环境、引用过期文档。
需要做好 数据源分级、版本管理、可追溯引用。
3. 自动执行风险
Auto 模式很爽，但风险最高。建议原则：
- 读操作可自动
- 写操作需确认
- 高风险操作默认禁止
4. 评估风险
Agent 输出看起来很完整，不代表它是对的。
测试团队需要建立 输出验证机制：测试点是否遗漏？脚本是否可维护？归因是否有证据链？
九、Craft Agents 给行业释放的信号
Agent 工具正在从 单点能力 走向 工作流系统。
过去我们关注：
- 模型能不能写代码？
- Agent 能不能调用工具？
- MCP 能不能接入更多服务？
接下来更重要的问题会变成：
- Agent 会话怎么管理？
- 任务怎么编排？
- 权限怎么控制？
- 输出怎么审计？
- 技能怎么复用？
- 怎么接入企业真实系统？
- 怎么和人的工作流协同？
这才是 Agent 工程化的主战场。
十、写在最后：Agent 的下一站，是可控的工程系统
Craft Agents 没有停留在“模型能力展示”，而是开始处理 Agent 真正落地时绕不开的问题：
任务、会话、权限、工具、数据源、技能、自动化。
真正能落地的 Agent 系统，必须满足三个条件：
- 能连接真实工作环境
- 能沉淀团队经验和流程
- 能在权限边界内稳定执行任务
对于测试开发同学来说，未来的测试能力不只是会写用例、会写脚本、会搭平台，更重要的是：
你能不能把测试流程、质量规则、自动化能力和 Agent 工作流结合起来。
Craft Agents 这类工具，正是这个变化的一个早期信号。
