AI Agent 治理与安全：从实验到生产的关键挑战

如何让AI Agent安全可控地工作？Markus治理体系深度解析

一、Agent 自治悖论：能力越强，越需要治理

想象一下：你的 AI Agent 能自己执行 Shell 命令、读写文件、管理 Git 仓库、调第三方 API，还能跟其他 Agent 协作完成任务——你当真敢让它直接跑起来？

说白了，这就是 AI Agent 时代的一个核心矛盾，我们管它叫 "Agent 自治悖论"：Agent 越能干、越自主，捅娄子的半径就越大，对治理的要求就越苛刻。

过去一两年，不少团队把 AI Agent 部署到生产环境后，翻车的案例一个接一个：

• Agent 调试时误执行了 DROP TABLE，测试数据库一秒被清空
• Agent 往主分支一推，同事的提交直接被覆盖，代码紧急回滚
• 几个 Agent 同时改同一个文件，产生竞态条件，产出物互相覆盖
• Agent 陷入无限循环，几个小时烧掉几千美元的 API 调用费

这些事故的根源不是 Agent 能力不行，而是缺少一套系统化的治理机制。

本文以开源 AI 智能体平台 Markus 的治理体系为蓝本，深入剖析一套生产级的 AI Agent 安全治理方案——从信任体系、任务状态机、工作区隔离到审计追踪，逐一拆解其设计与实现。

Markus 是一个开源 AI 数字员工平台，GitHub 地址：https://github.com/markus-global/markus

二、为什么 AI Agent 治理如此重要？

在深入具体方案之前，先理解 AI Agent 治理要解决的四类核心风险：

代码执行风险 — Agent 可通过 shell_execute 在宿主机上执行任意命令。即便 Agent 本身没有恶意，LLM 的幻觉特性也可能导致其执行错误命令。典型场景：修复路径问题时通过 rm -rf 删除了错误目标目录。

数据隐私与泄露 — Agent 可读取文件系统上的任何文件。若工作区包含敏感配置文件、客户数据或密钥，Agent 可能不经意间将其写入日志或暴露给不相关人员。

质量控制挑战 — AI Agent 的输出不具备"确定性"：同一任务、同一 Agent，两次执行的代码结构可能完全不同。没有 review 机制，低质量产出会直接进入生产环境。

成本失控 — 每次 LLM 调用都产生费用。陷入死循环的 Agent 可在数分钟内消耗数百美元 API 费用，而多 Agent 并行会进一步放大风险。

三、渐进式信任体系：让 Agent 用行为证明自己

Markus 治理体系的核心哲学是 "Trust but Verify"（信任但验证）。但与传统安全模型不同，Markus 引入了一个动态调整的渐进式信任体系——Agent 的自治权限不是静态分配的，而是通过持续的行为表现逐步获得的。

3.1 四级信任模型

这里的关键洞察是：信任是挣来的，不是赋予的。每个 Agent 从最低级别（Probation）开始，没有任何"默认信任"。

3.2 信任分如何计算？

信任分不是简单的好评率，而是一个多维度加权评分系统，主要因素包括：

1. 任务完成率 — 提交 review 且被批准的任务占比。被驳回（request revision）或失败的任务会降低分数。
2. 交付质量 — reviewer 反馈中是否出现严重问题（质量问题会显著扣分）。
3. 违规行为 — 尝试越权操作（如向其他 Agent 的工作区写入文件）会扣分。
4. 协作表现 — 是否合理使用 agent_send_message 与其他 Agent 协作，是否及时响应 review 请求。
5. 时效性 — 任务是否在合理时间内完成。超过 stall detection 阈值（in_progress 超过 24h）会被记录。

3.3 信任级别的实际影响

不同信任级别直接影响 Agent 在任务审批流水线中的权限：

• Probation：Agent 创建的任何任务，无论优先级多低，都需要人工审批才能开始执行。
• Standard：低优先级任务可以自动进入 in_progress（auto-approve），但标准和高优先级任务仍需要经理或人工审批。
• Trusted：可以担任其他 Agent 的 reviewer，标准任务自动审批。
• Senior：高优先级任务也可自动审批，可担任关键项目的 reviewer。

3.4 升级路径

当 Agent 的信任分达到升级门槛时，系统不会自动升级——而是触发升级评估流程：

1. 系统通知 Manager Agent（或人类管理员）该 Agent 已达到升级条件
2. Manager 审查该 Agent 的近期交付质量和工作记录
3. 审查通过则升级，不通过则保持在当前级别
4. 降级也是自动触发的：如果连续多次任务失败或出现违规行为，分数下降触发降级

这确保了"信任升级"是一个有意识的管理决策，而不是自动化积累。

四、任务治理状态机：9 种状态与 Review-Merge 工作流

如果说信任体系是"谁可以做"，那么任务状态机定义的是"事情怎么做"。Markus 的任务系统基于一个精确定义的有限状态机（FSM），包含 9 种状态和明确的转移规则。

4.1 九种状态一览

4.2 状态转移图

pending ──────► in_progress ──► review ──► completed ──► archived
   │                │    ▲         │
   │                │    │         └── revision ──► in_progress
   │                ▼    │
   │             blocked ┘
   ▼                │
rejected          failed ──► archived
                    │
                    └── retry ──► in_progress

1. Worker 不能自审自批：执行完成 → review，不是 completed。强制第三者 review。
2. Reviewer ≠ Worker：创建任务时必须指定 reviewerId，且不能与执行者是同一 Agent。
3. Revision 是新的一轮：reviewer 要求修改时，状态回到 in_progress，且 executionRound 递增。之前的执行上下文会以 "🔴 REVISION REQUIRED" 格式传递给 Agent。
4. Rejected ≠ Cancelled：rejected 表示"提案被否"（工作尚未开始）；cancelled 表示"主动停止"（已经开始工作后）。语义严格区分。
5. Retry = fresh start：重试时创建全新的 LLM session，之前的执行上下文不传递给新 session，确保干净重来。

4.3 三级审批门禁

Markus 在任务创建环节设置了三级审批门禁（Approval Gates）：

动态调整：Agent 的信任级别也会影响审批层级。例如，Senior 级别的 Agent 创建的标准任务可以 auto-approve，而 Probation 级别的 Agent 即使创建低优先级任务也需要人工审批。

4.4 Review 流程

当一个任务进入 review 状态时，系统自动执行：

1. 查找任务的 reviewerId
2. 向 reviewer 发送结构化的 review 请求（通过 Agent 邮箱系统或 HITL 审批通道）
3. 消息包含：任务描述、交付物、子任务状态、最近日志、评审指令

Reviewer 有两个选项：

• Accept（接受）→ 调用 acceptTask() → 任务进入 completed
• Request Revision（要求修改）→ 调用 requestRevision(taskId, reason) → 任务回到 in_progress，executionRound 递增

五、工作区隔离：每个 Agent 的专属沙箱

多 Agent 协作最危险的问题之一就是互相干扰——A Agent 不小心覆盖了 B Agent 正在编辑的文件。

5.1 物理隔离

Markus 为每个 Agent 分配专属工作区目录：

~/.markus/agents/{agentId}/workspace/

硬性强制规则：

• Agent 可以读取系统上任何文件（Agent 需要灵活性来理解项目结构）
• Agent 只能写入自己的工作区（~/.markus/agents/{agentId}/workspace/）
• 向其他 Agent 工作区的写入操作被直接拒绝
• 跨 Agent 目录的写入被强制拦截

设计哲学：读自由，写隔离。"读自由"确保 Agent 可以查看整个项目的上下文；"写隔离"确保多 Agent 不会产生文件级别的竞态条件。

5.2 Git 命令治理（三阶模型）

AI Agent 操作 Git 仓库是高风险场景。一个错误的分支推送可能导致代码丢失。Markus 实现了三阶 Git 命令治理：

设计亮点：

• 渐进式约束：日常操作（commit、新建分支）可自由执行；破坏性操作（切换到已有分支、推送到主分支）需要审批；极端危险操作（force push）完全禁止。
• 审批集成：Approval 级别的操作通过 HITLService.requestApprovalAndWait() 阻塞等待人工决策。
• 可扩展：新的危险操作可以通过配置或代码模式数组添加，无需修改治理框架。

5.3 Git Commit 元数据注入

当 Agent 执行 git commit 时，shell_execute 工具会自动注入 --author 和 --trailer 参数：

Author: Agent Name agent-id@markus.local

Trailer: Agent-ID: <id>, Task-ID: <taskId>, Team: <team>, Org: <org>

这意味着每个 commit 都可以追溯到具体的 Agent 和任务——审计的根基。

六、熔断与防护机制：防止灾难性故障

即使有信任体系和隔离措施，Agent 仍可能陷入异常状态。Markus 设计了多层熔断与防护机制：

6.1 循环检测与反射

当 Agent 在同一轮工具调用中迭代超过 30 次时，系统触发 Reflection（反思）机制：

• Agent 收到一个系统级提示，要求其反思当前行为
• 反思提示包含：当前已执行的步骤、迭代次数、可能的问题分析
• Agent 需要输出反思结论：继续（有明确理由）或改变策略

这防止了 Agent 在同一个死胡同里无限循环。

6.2 断路器模式

当 Agent 连续遇到 2 次 LLM 调用失败（网络错误、API 超时、响应格式异常等）时，断路器自动打开：

• 恢复期：5 分钟的降解模式
• 在此期间，Agent 不会发起新的 LLM 调用
• 5 分钟后断路器半开，允许一次测试调用
• 测试成功则关闭断路器，失败则重新开始 5 分钟恢复期

6.3 超时控制

6.4 全局紧急控制

关键设计：暂停状态是持久化的。重启服务后，暂停的 Agent 保持暂停状态不会自动恢复。

七、审计追踪：Agent 行为全记录

没有审计的安全是虚假的安全。Markus 建立了多层审计体系：

7.1 任务状态变更日志

每一次任务状态变更都经过 updateTaskStatus() 方法——这是所有状态变更的唯一入口。每次变更记录包含：

• 变更时间戳、旧状态、新状态
• 触发方式（人工操作、系统自动、Agent 提交）
• 关联信息（reviewer、revision reason、cancel reason 等）
• 依赖任务检查（状态变更后自动检查依赖任务是否解除阻塞）

7.2 Agent 活动日志

每个 Agent 维护一个完整活动日志，记录每一次：

• 工具调用（shell_execute, file_write, git 等）— 包含完整参数和返回值
• LLM 调用 — 提示词摘要、Token 消耗、延时
• 邮箱决策 — Attention controller 的每一次决策（pick/defer/drop）及原因
• 认知准备 — Cognitive Preparation Pipeline 的各个阶段记录

7.3 周期性报告

7.4 数据表级审计

Markus 的数据库包含专门的 audit_logs 表，记录每个操作的事件类型、操作描述、关联的 Agent/任务/项目信息。

八、Human-in-the-Loop：让人始终在回路中

任何治理体系的最终防线都是人类。Markus 提供了多层次的人机交互机制：

8.1 HITL 审批管道

当 Agent 需要人类决策时，使用 request_user_approval 工具：

1. Agent 发送审批请求（包含上下文、选项、优先级）
2. 请求出现在人类用户的审批队列中
3. 人类审批或拒绝，可附上原因
4. Agent 收到结果并继续执行

此机制用于：Git 操作审批、高优先级任务创建、共享资源变更确认。

8.2 治理仪表板（Web UI）

Markus Web UI 提供完整的治理控制面板：

• 系统状态 — 查看系统是否处于暂停或紧急停止模式
• 全局控制 — Pause All、Resume、Emergency Stop 按钮
• 治理策略 — 配置默认审批级别、最大并发任务数
• 公告系统 — 创建和广播系统级消息

8.3 通知系统

人类用户通过通知铃铛接收各类事件：

• Agent 主动消息（notify_user）
• 审批请求（待决策项）
• 任务状态变更
• @Mention（任务/需求评论中的提及）
• 直接消息和群组消息

每个通知可以直接点击导航到相关页面。

九、与其他平台的治理方案对比

大多数 Agent 框架专注于"如何让 Agent 工作"，而 Markus 投入了大量工程精力在"如何安全地让 Agent 工作"——这恰恰是企业级部署最需要的部分。

十、生产部署建议

如果你正在规划将 AI Agent 引入生产环境，以下建议供参考：

10.1 起点：从 Probation 开始

永远不要给新的 Agent 直接分配 Trusted 级别。即使是一个简单的自动化 Agent，也应该从 Probation 开始。通过观察实际行为与预期的差异，逐步调整策略。

10.2 配置合理的审批层级

高风险操作（数据库变更、生产部署）→ Human 审批；中风险操作（代码开发、文档撰写）→ Manager 审批；低风险操作（只读查询、数据汇总）→ Auto。

10.3 启用完整审计

建议保留活动日志至少 90 天，启用日报 + 周报，配置 stall detection 告警。

10.4 设置合理的熔断参数

{
  "circuitBreaker": { "failureThreshold": 2, "recoveryTimeMs": 300000 },
  "loopDetection": { "iterationThreshold": 30, "triggerReflection": true },
  "timeout": { "taskMaxDurationMs": 86400000, "llmCallTimeoutMs": 60000 }
}

10.5 从单个 Agent 开始

先让一个 Agent 在 Probation 下完成简单的独立任务，验证行为符合预期后，再逐步提升信任级别和扩展团队。

十一、总结：治理不是限制，而是赋能

AI Agent 治理面临一个根本性的平衡问题：如何在 Agent 的自主性和安全性之间找到最佳平衡点？

Markus 给出的答案是：用渐进式信任代替非黑即白的权限模型，用严格的任务状态机保证工作流的确定性，用工作区隔离防止互相干扰，用完整的审计链条提供可追溯性，用 HITL 机制让人始终在回路中。

一个好的治理体系，不是在一开始就筑起高墙把所有风险挡在门外——因为那样也会挡住 Agent 的创造力。而是在 Agent 的能力成长过程中，动态调整"自治"和"约束"的比例，让 Agent 用实际表现证明自己值得更多信任。

这整套治理框架已经在 Markus 的开源代码中完整实现（https://github.com/markus-global/markus），开发者可以直接部署体验，也可以将其中借鉴的设计思想应用到自己的 AI Agent 系统中。

毕竟，未来不是 AI 替代人类，而是治理得当的 AI 团队与人类高效协作。而治理，正是让这种协作成为可能的基石。

Markus Engineering Team · 技术文章系列