这几天 AI Agent 圈有一个很值得关注的信号：Agent 开始需要“目录”了。

6 月 17 日，GitHub 宣布 Agent Finder for GitHub Copilot 可用。它的核心不是再做一个聊天入口，而是让 Copilot 能从公共或私有目录中发现合适的 AI 资源。更关键的是，它实现了开放的 ARD（Agentic Resource Discovery） 规范。

Google 同期发布 ARD，描述得更直接：随着 Agent 生态扩大，工具、技能、MCP Server、其他 Agent 分散在不同团队、平台和组织里，Agent 需要可靠回答三个问题：

1. 能力在哪里？
2. 当前任务到底该用哪个能力？
3. 这个能力是否可信、是否安全、是否能连接？

这其实点到了企业 Agent 落地的一个核心矛盾：企业不是缺 Agent，而是缺一个能管理 Agent 能力的运行层。

一、为什么 Agent Finder / ARD 这件事值得关注？

过去一年，大家都在谈 MCP、Skills、Agent、工作流、插件、Function Calling。每个概念单独看都很有用，但企业真正用起来后，会很快遇到一个问题：能力太多了。

一个 Agent 可能能用：

• 内置工具；
• MCP Server；
• Skills；
• REST API；
• 数据库查询；
• 浏览器自动化；
• 代码执行；
• 其他 Agent；
• 工作流；
• 组织内部系统。

如果把所有工具 schema 全部塞进系统提示词，上下文会膨胀，模型会迷路，成本会上升，安全风险也会变大。

Agent Finder 和 ARD 代表的方向，是把“能力”从 prompt 里抽出来，变成一个可发布、可搜索、可验证、可按任务注入的目录。

这背后的思路非常清晰：不是让 Agent 记住所有能力，而是让 Agent 在需要时找到正确能力。

二、热点背后的共同趋势：Agent 正在产品化

如果把最近几条信息放在一起看，趋势会更明显。

OpenAI 的 Workspace Agents 强调团队共享、组织权限、Slack 入口、长任务和企业治理。Codex 插件则在把 Coding Agent 扩展到不同角色和知识工作流。GitHub Agentic Workflows 则把 Agent 放进 GitHub Actions，用于 issue triage、CI failure analysis、文档更新等持续任务。

这些产品方向并不完全相同，但共同点是：

• Agent 不再只是个人聊天框；
• Agent 要进入组织工作流；
• Agent 要调用工具和业务系统；
• Agent 要有权限边界；
• Agent 要能被审计和观察；
• Agent 要持续运行，而不是一次性回答。

这也是为什么我觉得 “Agent Finder / ARD” 这个选题比单纯讨论某个新模型更值得写。模型会持续变强，但企业真正需要的是一层把模型、工具、知识、权限和任务闭环组织起来的基础设施。

三、MateClaw 对应的不是“更多 Agent”，而是 Agent Harness

MateClaw 的定位可以从这个角度理解：它不是只提供一个聊天界面，而是在做企业 Agent 的 Harness。

所谓 Harness，不只是“套壳”。它要解决几个问题：

1. 模型怎么接入和切换；
2. 工具怎么注册和绑定；
3. 知识怎么供给和追溯；
4. 长任务怎么拆解和跟踪；
5. 高风险操作怎么审批；
6. 失败后怎么恢复或降级；
7. 结果怎么验收；
8. 多入口怎么共享同一个员工。

MateClaw 里已经有几个很接近 ARD 方向的内部结构。

1. Skills / MCP / ACP / Tools 统一进入能力层

MateClaw 支持内置 Tools、Skills、MCP 和 ACP。它们不是各自孤立地散落在系统里，而是进入统一的能力管理和员工绑定逻辑。

这点和 ARD 思路很像：能力不是写死在 prompt 里，而是可以被注册、发现、绑定和调用。

区别在于，ARD 更关注跨平台、跨组织的开放发现规范；MateClaw 当前更像企业内部的 Agent Harness，把这些能力收敛到具体数字员工身上。

如果未来 MateClaw 支持导出或导入 ai-catalog.json，就可以把内部 Skills、MCP、ACP、Tools 映射成可发现的企业能力目录。这会非常自然。

2. 员工级绑定，而不是全局裸奔

很多 Agent 工具系统的问题是：工具一接入，所有 Agent 都能看到；或者工具太多，全部进入上下文。

MateClaw 更合理的方式是：每个数字员工绑定自己的工具、知识库和技能。客服员工不应该默认拿到生产数据库操作工具；研发员工也不一定应该看到财务知识库。

这种 per-employee binding 很适合企业场景，因为它把能力和职责绑定在一起。

一个企业里的 Agent 不应该是一个“超级全能模型”，而应该是多个职责明确的数字员工：

• 产品研究员；
• 客服助理；
• 知识管理员；
• 数据分析员；
• 执行助理；
• 研发协作员工。

每个员工有自己的 Role、Goal、Backstory、工具集、知识范围和记忆。

这比“给一个大模型接一百个工具”更可控。

四、能力目录只是第一步，真正难的是运行治理

Agent Finder / ARD 解决的是“怎么发现能力”。但企业落地时，还要继续问：

• 调用这个能力要不要审批？
• 谁批准了？
• 结果有没有记录？
• 如果工具失败，Agent 会不会乱编？
• 如果模型供应商挂了，任务能不能继续？
• 如果任务跑了 20 分钟，用户能不能看到进度？
• 如果 Agent 使用了知识库，引用能不能追溯？

这些问题就是 MateClaw 的价值点。

MateClaw 已经有 Tool Guard、审批、审计、任务清单、Goal checklist、多模型 failover、LLM Wiki citations、MCP 缓存刷新等能力。它们不是单独的功能点，而是在构成一个 Agent Runtime。

一个完整的企业 Agent 闭环应该是：

1. 用户提出目标；
2. Agent 拆成计划；
3. 从能力目录中找到合适工具；
4. 按员工权限加载能力；
5. 高风险工具进入审批；
6. 执行后记录工具调用和结果；
7. Goal checklist 逐条验收；
8. 经验沉淀进 Memory / Wiki / Skills；
9. 下一次任务从更好的上下文开始。

这就是我理解的 Loop Engineering。

五、Loop Engineering：比“会调用工具”更重要

现在很多 Agent 演示都停留在“模型调用了一个工具”。但真正的工程问题是：调用之后发生什么？

一次真实任务不是单步调用，而是一个循环：

目标 → 计划 → 找能力 → 调工具 → 观察结果 → 自检 → 修正 → 继续 → 验收 → 沉淀

这个循环如果没有工程化，就会变成：

• 工具越接越多；
• prompt 越写越长；
• 权限越放越大；
• 结果越来越难验证；
• 失败越来越难排查；
• 成本越来越不可控。

MateClaw 的思路，是把这个循环做成可管理的运行层：

• ReAct 处理短循环；
• Plan-and-Execute 处理长任务；
• Goal checklist 做验收；
• Tool Guard 管高风险操作；
• LLM Wiki 提供可引用知识；
• Memory / Dream 做长期沉淀；
• 多模型 failover 保持任务不中断；
• Web Console / Desktop / IM Channels 提供多入口；
• Skills / MCP / ACP 提供能力扩展。

所以我更愿意把 MateClaw 看成一个 Loop Engineering Platform，而不是“又一个 AI 助手”。

六、CSDN 开发者可以关注什么？

如果你是 Java 或企业应用开发者，Agent Finder / ARD 这波热点至少值得关注三个方向。

1. 能力目录会成为企业 Agent 的基础设施

未来企业内部可能会有很多 agentic resources：

• 某个团队维护的 MCP Server；
• 某个部门发布的 Skill；
• 某个系统暴露的业务 API；
• 某个私有 Agent；
• 某个工作流模板。

这些能力需要目录、元数据、权限、审核和版本。否则越用越乱。

2. “按任务加载能力”会替代“把工具全塞给模型”

工具越多，越不能全部塞进 prompt。更好的做法是先发现、再筛选、再按需注入。

MateClaw 里 Skills / MCP / ACP / Tools 的统一注册和员工绑定，本质上已经在做这个方向。后续如果结合 ARD，会更容易把企业内部能力发布成可搜索目录。

3. Agent Runtime 会比模型接入更重要

模型接入会越来越标准化。真正拉开差距的是：

• 任务状态；
• 权限治理；
• 工具执行；
• 失败恢复；
• 成本控制；
• 审计记录；
• 结果验收；
• 团队协作入口。

这些都不是换一个模型 ID 能解决的。

七、MateClaw 可以怎么继续演进？

结合 ARD / Agent Finder 的方向，MateClaw 后续可以考虑几类增强：

1. 企业能力目录页
   把 Tools、Skills、MCP、ACP、Agent、Workflow 统一成一个 capability catalog。

2. ARD / ai-catalog 导入导出
   支持把内部能力暴露成标准目录，也支持发现外部能力后进入 MateClaw 的审批和绑定流程。

3. 能力评分与使用统计
   记录某个 Skill / MCP / Tool 的调用次数、失败率、平均耗时、审批次数和消耗成本。

4. 能力安全标签
   例如 read-only、write、network、file-system、code-execution、requires-approval。

5. 按任务推荐能力
   在 Agent 规划任务时，先从能力目录里找候选，再由 Tool Guard 和员工绑定规则决定是否可用。

这不是为了追热点，而是因为企业 Agent 的规模一旦上来，能力目录是必然需求。

八、结语

Agent Finder 和 ARD 的出现，说明 Agent 生态正在从“模型能力竞争”进入“能力连接和治理竞争”。

过去大家问：哪个模型最强？
现在开始要问：哪个能力能被发现？谁能调用？调用前是否需要审批？调用后是否能审计？结果是否能验收？失败后是否能恢复？

这正是 MateClaw 这类 Agent Harness 项目的机会。

如果说 MCP 让工具更容易接入，那么 ARD 让能力更容易被发现；而 MateClaw 要解决的是下一层问题：这些能力进入企业之后，如何被数字员工安全、可见、可验收地使用。

这才是企业 Agent 真正进入生产的门槛。

---

参考资料

• GitHub Agent Finder：https://github.blog/changelog/2026-06-17-agent-finder-for-github-copilot-now-available/
• Google ARD 规范介绍：https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/
• ARD Spec GitHub：https://github.com/ards-project/ard-spec
• GitHub Agentic Workflows：https://github.blog/changelog/2026-06-11-github-agentic-workflows-is-now-in-public-preview/
• OpenAI Workspace Agents：https://openai.com/index/introducing-workspace-agents-in-chatgpt/
• MateClaw 开源地址：https://github.com/mateaix/mateclaw
• MateClaw 文档：https://claw.mate.vip/docs
• MateClaw 在线演示：https://claw-demo.mate.vip