OpenTag 是一个用 TypeScript 编写的开源“@agent 提及”工作流框架，用于在 GitHub、Slack 等团队协作线程中直接调用 AI 编程代理。用户在 Issue、PR 评论或 Slack 线程中提及代理后，OpenTag 会将请求路由到本地或托管 Runner，由 Claude Code、Codex 或自定义 Executor 执行任务，并把结果、PR、审核记录或建议操作回写到原始线程。项目当前处于 v0 阶段，已验证 GitHub 和 Slack 的端到端流程，适合本地评估、集成实验和早期 SDK 试用。
适用领域
AI Agent 工作流 / 开发者工具 / GitHub 自动化 / Slack 协作自动化 / 代码生成与代码修改 / DevOps / ChatOps / AI 编程助手集成 / 本地 Runner / 私有代码执行
配置难度
中高。基础试运行只需要 Node 22、pnpm 和示例配置，但要完成真实 GitHub/Slack 集成、本地 Runner、Claude Code/Codex 执行、权限控制、审批和生产化部署，需要熟悉 GitHub App、Slack App、Webhook、Node 服务部署、CLI Agent、权限模型和安全审计。
商业价值
未知
01
技术亮点
- 把 AI Agent 带到开发者已有工作线程中，而不是要求团队切换到新的 AI 工作空间
- 支持 GitHub Issue、PR 评论和 Slack 线程的端到端 Agent 调用流程
- 支持本地优先执行，私有仓库、构建工具、凭据和上下文可以保留在团队自己的环境中
- 内置 Claude Code、Codex 和 echo Executor，并提供自定义 Executor 合约
- 通过 Dispatcher 管理运行请求、租约、心跳、审计日志和回调
- 支持安静回调模式，普通进度默认进入审计事件，源线程只接收确认、阻塞和最终结果
- 支持模型建议操作和线程内审批，例如 approve、apply、continue、reject
- 提供多个 npm 包，方便在自己的 Node 服务中嵌入 Dispatcher、Client、GitHub/Slack 适配器或 Runner
- 采用 MIT 许可证，适合二次开发和企业内部改造
- 已有真实冒烟测试验证 GitHub 到 PR、Slack 到本地 Claude Code、建议操作审批等核心路径
02
目标用户
- 希望在 GitHub Issue、PR 或 Slack 中直接调用 AI 编程代理的研发团队
- 需要把 Claude Code、Codex 或自定义 Agent 接入现有协作流程的开发者
- 关注私有代码安全，希望 AI 执行发生在本地 checkout 或受控环境中的团队
- 构建内部 AI Agent 平台、ChatOps 平台或研发自动化平台的工程团队
- 想开发 GitHub、Slack、飞书、Telegram 等工作应用适配器的集成开发者
- 需要可审计、可授权、可回滚 Agent 操作流程的企业研发组织
03
配置要求
- Node.js 22.x
- pnpm 9.x
- 需要配置 .env 文件，包含 Dispatcher、Runner、GitHub App、Slack App、回调地址等环境变量
- GitHub 集成需要配置 GitHub App、Webhook、仓库权限、Issue/PR 评论权限以及可选的 PR 创建权限
- Slack 集成需要配置 Slack App、事件订阅、Bot Token、App Mention 权限和线程回调权限
- 本地执行 Claude Code 需要安装并配置 claude CLI，执行方式为 claude --print
- 本地执行 Codex 需要安装并配置 codex CLI，执行方式为 codex exec
- Runner 需要绑定允许处理的 Project Target、仓库、频道或上下文范围
- 本地代码执行要求 checkout 状态安全；Claude Code 和 Codex Executor 会拒绝在脏工作区中运行
- 默认存储使用 SQLite/Drizzle，生产环境需要考虑数据库、租户隔离、持久化和运维部署
- 如果需要外部写入，例如创建 PR、修改标签、更新状态，需要显式配置对应能力和权限
04
适用场景
- 在 GitHub Issue 中 @OpenTag，让本地 Claude Code 根据 Issue 内容修改代码并创建 PR
- 在 Slack 线程中提及 Agent，让其分析问题、执行代码任务并将结果回写到线程
- 通过本地 opentagd 守护进程安全地让 AI 操作私有仓库，而不是把代码上传到第三方工作区
- 将模型建议的后续操作转化为需要人工批准的操作，例如添加标签、请求 Review、继续执行子任务或创建 PR
- 为团队搭建统一的 Agent 调度层，将 GitHub、Slack、未来的飞书或 Telegram 请求规范化为统一 Work Request
- 开发自定义 Runner 或 Executor，以接入内部模型、内部代码工具、CI/CD 系统或审批系统
- 通过审计日志记录每次 Agent 请求、上下文、执行者、结果和外部写入行为
05
部署与配置
- 确保本地安装 Node.js 22.x 和 pnpm 9.x。
- 克隆仓库：git clone https://github.com/amplifthq/opentag.git
- 进入项目目录：cd opentag
- 安装依赖：pnpm install
- 运行测试：pnpm test
- 运行协议冒烟测试：pnpm smoke:protocol
- 运行 Slack 协议冒烟测试：pnpm smoke:slack-protocol
- 构建项目：pnpm build
- 复制环境变量模板：cp .env.example .env，并根据实际 GitHub、Slack、Runner、Dispatcher 配置替换占位值。
- 如需完整本地 Runner 示例，可参考 examples/github-to-echo 或 examples/github-to-pr。
- 如需以包形式集成，可安装：pnpm add @opentag/core @opentag/client @opentag/dispatcher @opentag/github @opentag/slack @opentag/runner @opentag/store
06
风险与注意事项
- 项目仍处于 v0 阶段，官方明确定位为本地评估、集成实验和早期 SDK 反馈，生产稳定性需要谨慎评估
- 托管多租户控制平面仍属于未来强化方向，当前 Dispatcher 更适合作为轻量本地或单团队部署
- GitHub 和 Slack 是当前主要可用路径，Telegram 和 Lark/飞书适配器仍偏实验性质
- 依赖 Claude Code、Codex 等外部 CLI 工具时，需要额外处理认证、版本兼容、执行成本和输出稳定性
- Agent 具备修改代码和触发外部写入的能力，必须正确配置权限、审批、分支隔离和审计策略
- 本地 Runner 模式对团队机器环境、仓库路径、凭据管理和网络可达性有一定运维要求
- AI 自动生成代码可能引入质量、安全或合规问题，需要结合 Code Review、CI、测试和人工审批
- 如果错误配置 GitHub 或 Slack 权限，可能导致回调失败、权限过大或敏感信息暴露
2026-07-01
第14名
新收录 · github_search
2026-06-30
第16名
新收录 · github_search
2026-06-29
第17名
新收录 · github_search
2026-06-28
第17名
新收录 · github_search
2026-06-27
第19名
新收录 · github_search
