Agent 设计用于共享,但现有工具并不适用
摘要
作者讨论了跨团队共享 AI Agent 工作流的困难,并介绍了 Nairi,这是一款用于在 Slack 中部署基于 Claude Code 的 Agent 且支持共享访问的工具。
前一段时间,我在公司负责技术支持时收到了一张工单,报告某个功能无法正常工作。我没有亲自去翻查日志,而是让 Claude Code 来处理。我赋予了它访问我们支持工作区的权限、只读的 AWS 凭据,几分钟后它就给出了答案。这非常酷,我想把这种模式分享给团队。但这比我想象的要难得多。团队中有一半人使用的是 Cursor 或 Codex,而不是 Claude Code。而且最能从中受益的人甚至不在工程部门,而是销售和运营人员。我们曾尝试使用 Cursor 的后台 Agent,最初在我们的 Slack 中可用,但效果并不理想。每个人都需要付费席位,即使是那些从不打开 Cursor 的人。而且每个会话都绑定在一个用户身上,其他人无法在对话中途介入来纠正 Agent 的行为。于是我去构建了 Nairi (nairi.ai)。这是一个允许你在 Slack 中部署基于 Claude Code 的 Agent 的工具,团队成员可以共享使用。整个团队只需一个订阅。其他人是如何处理这个问题的?有什么好用的工具能让你在 Slack 中共享 Agent,或者你们也在自己构建这样的工具吗?我还写了一篇关于这个问题的博客文章,链接在评论区。
相似文章
AI 代理依然拉胯,于是我自己造了一个
作者构建了一款自定义 AI 代理应用,封装了 Claude Code 并即将支持 Codex,侧重于可组合的工作流,并期待社区反馈。
如今AI代理太多,却没有干净的方式来展示我们构建的成果
本文强调了在分散平台上管理和展示众多AI代理日益严重的问题,并介绍了HiFlixy作为创建有组织、可共享代理作品集的解决方案。
利用智能体编写高效的工具——借助智能体本身
Anthropic 分享了为 AI 智能体设计、评估和优化工具的工程最佳实践,特别介绍了如何利用模型上下文协议(MCP)和 Claude Code 来提升智能体的性能。
我构建了一个工作空间,让 Claude、Codex 和其他 AI 代理可以协作
作者构建了 AgentsHive,一个共享工作空间,将多个 AI 代理(如 Claude 和 Codex)协调成一个具有角色、记忆和路由的协作产品团队,让独立开发者无需手动切换不同的代理工作流。
是否有人也在为管理多个智能体工作流以及与他人设计的智能体协作而苦恼?我们为此打造了一个平台。
Commons 是一个新平台,旨在集中管理多个 AI 智能体工作流,并支持不同智能体之间的协作,从而解决上下文碎片化和界面分散的问题。