内容
# Baron
> **从 backlog 到部署的单窗格 — 为 AI 编程代理。**
> 通过单一标准化的接口驱动问题、分支、PR、CI、部署和通知，适用于任何技术栈，而不是将供应商的 API 硬编码到您的提示中。
## 问题
AI 编程代理将 **供应商的 API** 和 **团队的流程** 硬编码到提示中。当您的问题存在于 Azure DevOps 但代码位于 GitHub 上，或者您的板块列名称不是字面上的 "待办 / 已完成"，或者您在下一个季度切换跟踪器 — 提示就会中断，代理会退回到原始的、供应商特定的工具。您已经将供应商锁定硬编码到您的工作方式中。
## Baron 的作用
Baron 在代理和您的提供商之间提供了一个 **标准化的接口**。代理使用一种抽象的词汇 — 工作项、分支、PR、CI 运行、部署、通知，以 **角色** 的形式（`backlog → ready → in_progress → in_review → done`，加上 `blocked`）— Baron 将其翻译为每个提供商的实际 API、状态和特殊情况。自由混合提供商（Linear 问题 + GitHub PR + Slack 通知）。**相同的提示，任意技术栈。**
## 效果展示
```
您：启动任务：为登录端点添加速率限制。
Baron ▸ 运行任务启动示例为 ONE 确定性调用：
✓ 创建 STORE-142 "为登录端点添加速率限制" （类型角色：任务）
✓ 从存储库的默认分支分出 feature/STORE-142
✓ 将 STORE-142 移至 in_progress
✓ 评论： "在分支 feature/STORE-142 上开始。"
```
在 **Azure DevOps** 上，相同的提示会将工作项状态设置为 `Active`；在 **GitHub** 上，它会应用一个 `in-progress` 标签 — 因为 `in_progress` 是一个 *角色*，而不是供应商状态。您在 `baron init` 时确认了此映射。代理永远不会学习供应商的列名称，工作流程的顺序由 Baron's 引擎强制执行，而不是由模型即兴发挥。
## 为什么不同
- **能力端口，而非 "跟踪器"。** `issues` / `scm` / `ci` / `deploy` / `notify`，每个都独立绑定到提供商 — 因此消费者可以混合提供商，而不是押注于一个供应商涵盖所有内容。
- **标准化，而不是原始代理。** 新能力成为一流的标准化端口；一个明确标记的提供商原生逃生舱是明确的最后手段，而不是默认路径。
- **能力差距从不沉默。** 当提供商缺乏某些东西（例如，原生问题层次结构）时，Baron 要么模拟它（例如，标签），要么降级并警告，要么大声报错 — 由策略决定，从不被吞噬。
- **工作流程是确定性示例。** 多步骤流程（`task-start`、`task-finish`、`ship`）是声明性 YAML，以一个规则强制执行的调用运行 — 引擎强制执行步骤顺序，代理不执行。
## 快速开始
Baron 从源代码运行（无需构建步骤 — 工作区包解析为 TypeScript 源代码）：
```bash
pnpm install
# 1. 配置：检查提供商并编写 .baron/policy.json（您确认角色映射）
pnpm baron init --provider azure-devops # 或：--provider github
# 2. 添加凭证（环境变量或 .baron/credentials — 永远不会提交）。对于 Azure DevOps：
# AZURE_DEVOPS_ORG, AZURE_DEVOPS_PROJECT, AZURE_DEVOPS_REPO, AZURE_DEVOPS_TOKEN
# 3. 检查策略是否与实时提供商冲突
pnpm baron doctor
# 4. 运行工作流程示例
pnpm baron run --recipe packages/recipes/recipes/task-start.yaml
```
或者，将 **MCP 服务器** 连接到您的代理，并直接调用工具，跨越每个端口 —
`baron_issue_create`、`baron_scm_pr_create`、`baron_ci_runs`、`baron_deploy_deployments`、
`baron_notify_send`，以及用于整个工作流程的 `baron_recipe_run`。在 Claude Code 中，插件还附带每个示例的 **技能**（`/baron:task-start`，`/baron:ship`）。参见 [docs/mcp.md](./docs/mcp.md)。
新来者？ [Azure DevOps 设置演练](./docs/setup-azure-devops.md) 是从头开始复制粘贴（PAT 范围，`init → doctor → MCP`，故障排除）。
## 提供商
| 提供商 | 端口 |
| --- | --- |
| **Azure DevOps** | `issues` · `scm` · `ci` · `deploy` |
| **GitHub** | `issues` · `scm` · `ci` · `deploy` |
| **Slack** | `notify` |
更多适配器（Jira、Linear、GitLab、Notion）正在路线图中 — 增加一个适配器不会改变代理与 Baron 交互的方式。
## 文档
| 指南 | 内容涵盖 |
| --- | --- |
| [快速入门](./docs/getting-started.md) | 安装、先决条件、第一个 `init` → `doctor` → `run`。 |
| [设置演练 — Azure DevOps](./docs/setup-azure-devops.md) | 从零开始、复制粘贴设置 Azure DevOps + Claude Code。 |
| [概念](./docs/concepts.md) | 端口、角色、能力差距、知识循环 — 思维模型。 |
| [配置](./docs/configuration.md) | `.baron/policy.json`，角色/类型/差距映射、凭证。 |
| [CLI](./docs/cli.md) | `baron init` / `doctor` / `run` 参考。 |
| [示例](./docs/recipes.md) | 编写 YAML 示例：`ask` / `do` / `message`，插值，操作表。 |
| [MCP 服务器和插件](./docs/mcp.md) | MCP 工具和 Claude Code 插件。 |
| [与 Claude Code 试用](./docs/trying-with-claude-code.md) | 实践：连接 MCP 服务器到真实项目 + 验证检查清单。 |
| [提供商](./docs/providers.md) | 哪些提供商支持哪些端口和能力。 |
| [演示脚本](./docs/demo.md) | 准备好录制的 60 秒 "单窗格" 演示（Claude Code 或 CLI）。 |
完整的设计决策记录在 [ARCHITECTURE.md](./ARCHITECTURE.md) 中；贡献者工作合同在 [CLAUDE.md](./CLAUDE.md) 中，贡献条款在 [CONTRIBUTING.md](./CONTRIBUTING.md) 中，发布手册在 [RELEASING.md](./RELEASING.md) 中。
## 状态
v1 已构建端到端：`issues`、`scm`、`ci` 和 `deploy` 端口跨越 **Azure DevOps** 和 **GitHub**，以及通过 **Slack** 的 `notify`，配置引擎（`baron init` / `doctor`），多端口 MCP 服务器，YAML 示例引擎 + `baron run`，知识循环和 Claude Code 插件。每个适配器都通过了一个无网络的 **一致性套件**；Azure DevOps 端口还额外 **实时验证** 了一个真实项目。GitHub/Slack 的实时验证正在进行中。
## 许可证
开放核心。核心、P0 适配器（Azure DevOps、GitHub、Slack）、示例和 CLI/MCP 服务器根据 [Apache-2.0](./LICENSE) 许可。未来商业层面的功能（SSO、秘密管理器集成、多团队治理、审计）将根据单独的商业许可发布 — 参见 [ARCHITECTURE.md](./ARCHITECTURE.md) 决策 #20。
