为什么我花了 6 个月为 AI agents 构建护栏

Source: Dev.to

下面说说我为什么构建它，它是如何工作的，以及我学到了什么

问题：AI 代理功能强大，却让人害怕

我一直痴迷于 AI 代理——不是聊天机器人，而是能够实际执行任务的代理。它们可以：

• 合并 Pull Request
• 部署到 Kubernetes
• 更新数据库记录
• 代表你发送 Slack 消息

技术已经成熟。但每次我尝试将其投入生产时，都会出现同样的情况：

安全团队说不行。

说实话？他们说得对。

想想看：你让 AI 有权写入生产系统，却没有审计日志、审批工作流，也没有办法强制执行策略。这就像给实习生 root 权限，然后祈祷一切顺利。

我不断看到团队卡在我称之为**“PoC 地狱”**的状态——精彩的演示从未上线，因为缺少治理方案。

解决方案：先策略后调度

如果每一次 AI 行动都必须在执行前通过策略检查怎么办？

这就是 Cordum 的核心理念。

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│   AI Agent  │ --> │ Safety Kernel│ --> │   Action    │
└─────────────┘     └──────────────┘     └─────────────┘
                           │
                    ┌──────┴──────┐
                    │   Policy    │
                    │ (as code)   │
                    └─────────────┘

在任何作业执行之前，Safety Kernel 会评估你的策略并返回以下结果之一：

• ✅ Allow – 正常继续
• ❌ Deny – 阻止并给出原因
• 👤 Require Approval – 人工介入
• ⏳ Throttle – 限流

给我代码看看

下面是一个策略的示例：

# policy.yaml
rules:
  - id: require-approval-for-prod
    match:
      risk_tags: [prod, write]
    decision: require_approval
    reason: "Production writes need human approval"

  - id: block-destructive
    match:
      capabilities: [delete, drop, destroy]
    decision: deny
    reason: "Destructive operations not allowed"

  - id: allow-read-only
    match:
      risk_tags: [read]
    decision: allow

当代理尝试执行危险操作时，Cordum 会介入：

{
  "job_id": "job_abc123",
  "decision": "require_approval",
  "reason": "Production writes need human approval",
  "matched_rule": "require-approval-for-prod"
}

作业会在仪表盘中等待人工批准。完整审计日志。合规部门满意。

架构

Cordum 是一个控制平面，而不是代理框架。它负责调度和治理代理——并不取代 LangChain 或 CrewAI。

┌─────────────────────────────────────────────────────────┐
│                Cordum Control Plane                     │
├─────────────────────────────────────────────────────────┤
│  ┌───────────┐  ┌──────────────┐  ┌─────────────────┐ │
│  │ Scheduler │  │ Safety Kernel│  │ Workflow Engine │ │
│  └───────────┘  └──────────────┘  └─────────────────┘ │
├─────────────────────────────────────────────────────────┤
│  ┌───────────────┐  ┌───────────────────────────────┐ │
│  │  NATS Bus     │  │  Redis (State)                  │ │
│  └───────────────┘  └───────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
         │                    │                    │
    ┌────┴────┐          ┌────┴────┐          ┌───┴────┐
    │ Worker   │          │ Worker   │          │ Worker │
    │ (Slack)  │          │ (GitHub) │          │ (K8s)  │
    └──────────┘          └──────────┘          └────────┘

技术栈

• Go – 核心控制平面（约 15 K 行）
• NATS JetStream – 至少一次投递的消息总线
• Redis – 作业、工作流、上下文的状态存储
• React – 实时更新的仪表盘

性能

• （性能细节在摘录中省略）

构建过程中的收获

1. 安全是特性，而非约束
   我最初把治理视为“必要的恶”，是一种必须接受的限制——但实际上它可以是产品的核心价值。

企业对合规性的需求。但我已经把它视为一个 特性。

(其余课程内容在原文中继续)

1. “写入权限”是竞争优势

当每一次 AI 行动都经过政策评估并被记录时，你将解锁以前不可能的使用场景。

• Banks 可以使用 AI 代理。
• Healthcare 可以使用 AI 代理。

“写入”能力成为强大的差异化因素。

2. 协议的重要性超出我的预期

• 工作者可以使用任何语言编写。
• 控制平面可以独立演进。
• 第三方可以构建兼容的工具。

3. 开源是一种分发策略

我本可以从第一天起就把它做成闭源 SaaS，但开源为我们带来了：

• 信任 – 你可以阅读代码。
• 自托管 – 企业非常喜欢。
• 社区渠道 – 用户贡献并传播口碑。

商业模式： open‑core。自托管永久免费；云/企业功能付费。

接下来

路线图包括：

• Helm chart 用于 Kubernetes 部署。
• Cordum Cloud – 托管版。
• Visual workflow editor 在仪表板中。
• More packs – AWS、GCP、PagerDuty 等。

试一试

🌐 网站:
📦 GitHub:
📋 协议:
📚 文档:

如果你正在构建 AI 代理并希望内置治理，请尝试一下。如果觉得有用，请给仓库加星 ⭐

感谢阅读！我很乐意在评论中回答问题。