Cordum Agent Control Plane
在高风险 AI 操作执行前，用策略、审批与审计证据实施控制。
按维度查看评分与理由
证据显示：README 描述了策略评估、人工审批、输出隔离、审计追踪等治理功能；Edge 部分明确要求审批和证据导出；SDK 示例中 AllowUnsigned 需显式设置，默认 fail-closed。扣分：未提供具体的最小权限配置示例，且未验证实际执行效果。
证据显示：README 和 CI 工作流一致，CI 包含测试、集成测试、lint、安全扫描等；依赖版本固定，有 go.sum 和 pnpm-lock.yaml。扣分：未提供失败消息的具体示例，且未验证实际运行。
证据显示：README 提供了多种部署方式（docker compose、Helm、源码安装），支持多种环境；Edge 针对 Claude Code 有专门文档；SDK 支持 Go、Python、Node。扣分：未明确说明能力边界和触发条件的具体配置。
证据显示：README 结构清晰，有快速开始、文档链接、架构图；安装说明详细；命名一致；有示例和 FAQ；许可证为 BUSL-1.1；有版本号和 CI 徽章；维护责任在 README 中提及。扣分：未明确列出已知限制。
证据显示：README 提供了清晰的输出示例（如 demo 表格），价值主张明确，成本效益分析隐含在快速开始中。扣分：未提供性能或资源消耗数据。
证据显示：README 中的声明与代码和 CI 工作流一致，如 cosign 签名、CI 测试等；有多个来源（README、CI、SECURITY.md）相互印证；事实与推断区分明确。扣分：未提供独立验证结果。
- 静态审查，未实际运行，所有评分基于源码和文档。
- 发布者身份未验证，需谨慎对待。
- 默认密码 'ChangeMe123!' 和 API key 生成方式需在生产环境更改。
- BUSL-1.1 许可证可能限制某些商业用途。
这个 Agent 能做什么，适合哪些场景？
Cordum 是一个可自托管的 Agent 控制平面，用于在自主 Agent 执行前评估策略、阻断操作或要求人工审批。其完整栈包含 API Gateway、Scheduler、Safety Kernel、Workflow Engine、Context Engine、NATS、TLS 保护的 Redis，以及 React Dashboard。工作负载通过 Gateway 提交，Scheduler 与 Safety Kernel 进行治理判定，工作流和 Worker 可通过 CAP 协议执行并回传审计事件。它还提供 MCP 的 stdio 与 HTTP/SSE 接口，并通过 Cordum Edge 为 Claude Code 工具调用提供本地命令钩子、审批流程和脱敏证据导出。部署边界包括 Docker Compose、Helm/Kubernetes 和 Go SDK；Python 与 Node SDK 以独立包形式列出。
客户端可向 POST https://localhost:8081/api/v1/jobs 提交含 topic 与 prompt 的任务，并使用 X-API-Key 和 X-Tenant-ID 认证。API Gateway 接收任务，Scheduler 协调 Safety Kernel 的策略评估，判定可为 ALLOW、DENY 或 REQUIRE_APPROVAL；Workflow Engine 负责工作流编排。CAP Worker 可用 runtime.Register 注册如 job.summarize 的主题处理函数并由 agent.Start() 启动。cordumctl edge claude 会生成临时 settings.json、启动本地 loopback nonce 上的 cordum-agentd，再以命令钩子治理 Claude Code 的工具调用；审批后的破坏性操作还需匹配同一 tenant、approval_ref 和 action_hash 的已解决审批审计事件。平台可通过 Dashboard 展示会话时间线，并导出脱敏证据包。
- 平台工程团队在生产变更前，需要用策略和人工审批治理由 Agent 发起的 Terraform、Kubernetes 或云操作。
- 使用 Claude Code 的开发团队希望在终端拦截危险命令、对 Edit/Write 请求审批，并保留会话证据。
- 构建 CAP 兼容 Worker 的 Go 开发者，需要为
job.*主题的任务处理加入控制平面策略判定。 - 安全与合规团队需要在多个 Agent 池之间集中查看审批、策略结果和审计事件。
- 采用 MCP 工具集成的团队，需要通过
cmd/cordum-mcp的 stdio 模式或 Gateway 的/mcp/message、/mcp/sse接入治理路径。
这个 Agent 有哪些优点和局限？
- 在执行前由 Safety Kernel 给出允许、拒绝或要求审批的明确判定，而非只记录事后结果。
- Cordum Edge 为 Claude Code 提供命令钩子、本地
cordum-agentd、已解决审批溯源校验及脱敏证据导出。 - 同时提供 CAP Worker 运行时、MCP stdio/HTTP/SSE 接口、Docker Compose 和 Helm 部署路径。
- 发布镜像覆盖 linux/amd64 与 linux/arm64，并说明 release-tag 镜像使用 cosign keyless OIDC 签名。
- 完整本地部署要求 Docker、Compose、至少 4 GB Docker 内存；首次证书生成还要求 Go 1.26.3+。
- Edge 当前明确覆盖 Claude Code；企业级强制执行还依赖受管 Claude 设置和端点控制。
- 默认兼容设置为
CORDUM_SDK_HANDSHAKE=off与CORDUM_HEARTBEAT_MODE=authority；启用更严格模式前需要配置 Worker 证明密钥和控制平面签名授权方。 - 许可证为 BUSL-1.1：可自托管内部使用和修改贡献，但不得提供竞争性托管服务，至 2029-01-01 才转换为 Apache-2.0。
如何安装或部署这个 Agent？
准备 Docker Desktop v4+（或 Docker Engine v20.10+ 与 Compose v2）、至少 4 GB Docker 内存、Go 1.26.3+ 和 curl。执行：
git clone https://github.com/cordum-io/cordum.git
cd cordum
./tools/scripts/quickstart.sh该脚本启动完整栈并生成密钥与证书。完成后 Dashboard 位于 http://localhost:8082；初始登录为 admin / ChangeMe123!，应在暴露服务前修改 .env 中的密码。
如何使用这个 Agent？
先加载脚本生成的凭据：export CORDUM_API_KEY=$(grep CORDUM_API_KEY .env | cut -d= -f2)。然后提交首个任务：
curl -sS --cacert ./certs/ca/ca.crt -X POST https://localhost:8081/api/v1/jobs -H "X-API-Key: $CORDUM_API_KEY" -H "X-Tenant-ID: default" -H "Content-Type: application/json" -d '{"topic":"job.default","prompt":"hello"}'要运行内置三判定演示，执行 cordumctl pack install ./demo/quickstart/pack，再执行 cordumctl demo run quickstart。对已启动的平台启用 Claude Code Edge 时，设置 CORDUM_GATEWAY、CORDUM_API_KEY、CORDUM_TENANT_ID=default，然后运行 ./bin/cordumctl edge claude。
这个 Agent 与同类方案有什么区别？
仓库将 Cordum 与 Guardrails AI、NeMo Guardrails 和自定义中间件对比：其声称的差异包括执行前 Safety Kernel、内置人工审批、多 Agent 池治理、确定性审计、CAP 框架无关接入，以及 MCP Bridge/Gateway 和 Claude Code 本地操作防火墙。该比较为仓库自身的功能定位。
常见问题
Cordum 是否只适用于某一种模型或 Agent 框架？
能否不从源码构建就部署？
docker compose pull && docker compose up -d 拉取发布镜像；该路径仍需先用 go run ./cmd/cordumctl generate-certs 生成本地证书，并设置 API Key 与 Redis 密码。Claude Code 的审批如何防止仅凭请求事件放行？
approval_ref、action_hash 的已解决审批记录和规范的已解决审批审计事件；仅有审批请求事件不足以作为证明。生产部署时应注意什么凭据问题？
.env 中的管理员密码。Helm 文档还指出，生产环境应避免在命令行传入 API Key 或 Redis 密码，因为这些值会进入 Helm release 存储值和 shell 历史。