Craft Agents 爆火：Agent 工具正在从“命令行玩具”走向“工作流系统”

开源地址GitHub 项目lukilabs/craft-agents-oss当前 GitHub 页面显示该项目已达到5.8k Star、779 Fork同时还有较活跃的 Issue 和 PR 讨论。https://github.com/lukilabs/craft-agents-oss最近Agent 类开源项目又火了一个。项目名叫Craft Agents。它不是又一个“给大模型套壳的聊天工具”也不是简单把几个 MCP 工具接起来而是试图解决一个更具体的问题当 Agent 真正进入日常工作流后我们到底该怎么管理它、调度它、连接工具、控制权限并让它持续执行任务这也是 Craft Agents 值得关注的地方。过去很多人用 Agent体验大概是这样的打开一个终端输入一段 Prompt等模型调用工具、改代码、读文件、跑命令。能用但很“工程师自娱自乐”。一旦任务变多就会出现几个问题多个 Agent 会话怎么管理哪个任务正在跑哪个任务需要确认Agent 能不能连接 Gmail、Slack、Linear、GitHub、Notion权限怎么控制哪些能只读哪些必须人工确认长任务能不能后台跑能不能像管理工单一样管理 Agent 任务Craft Agents 的出现某种意义上说明了一件事Agent 工具正在从 CLI 阶段进入桌面工作台阶段。阅读目录Craft Agents 到底是什么为什么它会突然火起来它解决的不是“聊天”而是 Agent 工作流管理Craft Agents 的核心能力拆解它和 Claude Code、MCP、普通 AI 聊天工具有什么区别从架构角度看Craft Agents 做对了什么对测试开发、自动化测试、研发效能有什么启发这类 Agent 工具的真实风险在哪里写在最后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 这类工作台多任务管理多个窗口/上下文混乱多 Session 管理工具接入手工配置居多Sources / MCP / API 接入权限控制容易一把梭Explore / Ask / Auto 分级长任务执行容易中断Background Tasks过程追踪看聊天记录状态流转与会话归档Craft Agents 的设计思路很清楚不要只把 Agent 当成聊天对象而要把 Agent 当成工作流节点。这对研发、测试、运营、文档、项目管理都有启发。四、Craft Agents 的核心能力拆解根据项目 READMECraft Agents 提供了不少关键功能包括多会话收件箱、多模型连接、Craft MCP 集成、Sources、权限模式、后台任务、动态状态系统、多文件 Diff、Skills、文件附件和自动化能力等。([GitHub][1])可以拆成几个核心模块来看。1. Multi-Session InboxAgent 任务也需要“收件箱”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. SourcesAgent 不只是读文件而是连接真实系统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 ModesAgent 能力越强越需要权限边界Agent 工具最容易被忽略的一个问题是权限。很多人刚开始用 Agent 时会觉得“直接让它自动执行不就好了”但在真实工程环境里这很危险。比如 Agent 可能会删除文件修改配置执行命令调接口改数据库推送代码操作线上系统所以一个成熟的 Agent 工具必须有权限分层。Craft Agents 提供了三种权限模式模式含义适合场景Explore只读探索阻止写操作查资料、读代码、分析日志Ask to Edit修改前需要确认改代码、改文档、调配置Auto自动批准命令沙箱环境、低风险自动化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日志排查 SkillPlaywright 脚本生成 Skill测试报告总结 Skill缺陷复盘 Skill自动化框架改造 Skill这类 Skill 的意义不是简单“写一段提示词”。而是把团队里的经验、约束、流程、模板和工具调用方式封装起来。以后新人不用重新摸索Agent 也不用每次从零理解。5. AutomationsAgent 开始进入事件驱动阶段Craft Agents 的 README 提到 Automations可以基于标签变化、时间计划、工具使用等事件创建 Agent sessions。([GitHub][1])这其实很重要。因为 Agent 的下一步不只是“我问它答”而是当某个事件发生时Agent 自动进入工作流。比如测试场景里新需求进入评审状态自动生成测试点PR 创建后自动分析变更影响范围CI 失败后自动读取日志并归因线上告警后自动生成初步排查报告每天定时汇总缺陷趋势每周自动整理测试覆盖率变化这就是从 Chatbot 到 Agent Workflow 的变化。五、它和 Claude Code、MCP、普通 AI 聊天工具有什么区别可以用一张表理解。工具类型主要解决什么典型能力局限普通 AI 聊天工具问答与内容生成对话、总结、写作工作流弱工具接入有限Claude Code / Codex 类工具代码工程任务读代码、改代码、跑命令偏开发场景任务管理较弱MCP工具协议与连接层让模型调用外部工具本身不是完整工作台Craft AgentsAgent 工作台多会话、Sources、权限、后台任务、自动化仍需验证真实复杂场景稳定性所以 Craft Agents 不是简单替代 Claude Code也不是替代 MCP。更准确地说MCP 更像连接协议Claude Code 更像代码执行代理Craft Agents 更像 Agent 工作台。它把模型、工具、数据源、权限、会话和自动化流程放在一个桌面应用里管理。六、从架构角度看Craft Agents 做对了什么可以用下面这张结构图理解 Craft Agents 的核心设计。这个架构里最值得关注的不是某一个功能而是它的分层方式UI 层让 Agent 工作可视化Session 层让任务可管理Agent 层让模型可替换Sources 层让上下文可扩展Permission 层让执行可控Skills 层让经验可复用Automation 层让流程可触发这比单纯做一个聊天框更接近工程化。七、对测试开发、自动化测试、研发效能有什么启发Craft Agents 对测试开发从业者很有参考价值。因为测试工作天然就是“多系统、多数据、多流程、多角色”的工作。一个测试同学每天可能要接触需求文档接口文档代码仓库测试用例自动化脚本CI/CD 日志缺陷平台线上监控测试报告项目群消息这些信息分散在不同平台里。如果 Agent 只会聊天价值有限。但如果 Agent 能连接这些系统并按权限规则执行任务它就可能真正进入测试工作流。场景 1需求进入评审自动生成测试分析这类场景最适合 Agent。因为它不是替代测试工程师而是把重复的信息整理工作提前完成。测试工程师真正要做的是判断哪些风险最关键哪些历史问题需要回归哪些场景不能漏哪些接口需要重点验证哪些用例必须自动化场景 2CI 失败后自动做初步归因这类工作不是“很难”但很耗时间。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 系统一定要满足三个条件能连接真实工作环境能沉淀团队经验和流程能在权限边界内稳定执行任务对测试开发同学来说这个趋势尤其值得重视。未来的测试能力不只是会写用例、会写脚本、会搭平台。更重要的是你能不能把测试流程、质量规则、自动化能力和 Agent 工作流结合起来。因为 AI 不会只改变开发也会重构测试。而 Craft Agents 这类工具正是这个变化的一个早期信号。