契约驱动的多服务编排
一个 Hub,多个服务。
AI Agent 遵守边界。

Accord 用契约作为真理之源来协调微服务间的 AI Agent。Hub 分发任务、Agent 在各自仓库执行、Git 追踪每一次变更。

$ npm install -g @aion0/accord
$ accord-server start
✓ hub: http://localhost:3000 · 4 services discovered
════════════════════════════════════════════════════════════════
# 要解决的问题

你有 5 个微服务、3 个 AI Agent、2 个人类开发者在维护。一个团队需要一个 API 变更,影响三个服务。谁来协调?怎么追踪变更?怎么确保 Agent 不会破坏彼此的契约?

Accord 让契约成为真理之源。每个服务声明自己的 API 契约,每个变更请求被追踪,每个 Agent 在自己的服务边界内工作。

────────────────────────────────────────────────────────────────
# 工作原理
  ┌─────────────────────────────────────────────────────────┐
  │  A C C O R D   H U B                                    │
  │                                                         │
  │  Dashboard · Dispatcher · 契约注册 · 审计                │
  └──────┬──────────────────┬─────────────────────┬─────────┘
         │                  │                     │
         ▼                  ▼                     ▼
  ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
  │ demo-engine  │   │ device-mgr   │   │  frontend    │
  │              │   │              │   │              │
  │ 维护者:      │   │ 维护者:      │   │ 维护者:      │
  │ ai           │   │ ai           │   │ human        │
  │              │   │              │   │              │
  │ OpenAPI 契约 │   │ OpenAPI 契约 │   │ 内部契约     │
  │              │   │              │   │              │
  │ Claude Code  │   │ Claude Code  │   │ zhang@co.    │
  └──────────────┘   └──────────────┘   └──────────────┘
────────────────────────────────────────────────────────────────
# 核心概念
📜 契约
每个服务通过 OpenAPI(外部)和 Markdown(内部)契约声明 API 边界。契约存在 Git 中。变更被追踪、校验,并通知依赖方。
外部 API 用 OpenAPI · 内部约定用 Markdown · Git 作为真理之源
🔀 调度器
Hub 接收变更请求,根据维护者类型路由到对应服务。AI 服务自动执行,人工服务发通知,混合服务先审批再执行。
依赖检查 · 排他性(每个服务同时只有一个任务) · 优先级排序
🤖 维护者类型
每个服务声明由谁维护,调度器据此路由。
ai
全自动。Agent 接收任务、执行、提交代码、更新契约。
human
开发者收到通知(Slack/UI),手动完成工作后标记完成。
hybrid
Agent 制定计划,人审批,Agent 执行。
external
跨团队。请求路由到其他团队的 Hub。
📊 Dashboard
实时查看所有服务、待处理请求、Agent 执行流、契约 diff 和成本追踪。在 UI 上审批或拒绝 hybrid 请求。
🔗 A2A 协议
基于 Agent-to-Agent 协议(Linux Foundation)构建。标准化服务发现(Agent Card)、流式执行(SSE)、异步通知(Webhook)。任何兼容 A2A 的 Agent 都可接入。
────────────────────────────────────────────────────────────────
# 请求生命周期
  创建请求              "给 demo-engine 添加 GET /api/v1/policies"
       │
       ▼
  调度器                检查依赖 → 检查排他性 → 路由
       │
       ├── 维护者: ai ──────────► Agent 执行 → 提交 → 完成
       │
       ├── 维护者: hybrid ──────► Agent 计划 → 人审批 → 执行
       │
       └── 维护者: human ───────► 通知 → 人工作 → 标记完成
       │
       ▼
  契约更新              OpenAPI patch 校验 → Git commit → 通知依赖方
────────────────────────────────────────────────────────────────
# 实际案例

Accord 为真实项目设计:重构一个网络准入控制平台(FortiNAC),6 个 Java 微服务,由 AI Agent 和人类开发者混合维护。

6 个微服务 (Java Spring Boot)
4 个由 AI Agent (Claude Code) 维护
2 个由人类开发者维护
15+ 个 OpenAPI 契约定义服务边界
1 个 Hub 协调所有请求、契约和审计
════════════════════════════════════════════════════════════════
契约定义边界。Agent 遵守它们。