Agent 开发正在降温，但「可治理」的火才刚点起来

背景：榜单里的风向变化

翻了一下最近 GitHub 的热门项目榜单，一个很有意思的现象：2026 年上半年霸榜的 Agent 项目，几乎都在比拼"能干多少活"------能不能一口气写完一个项目、能不能并行跑 20 个任务、能不能把上下文塞到 100 万 token。而最近的榜单风格明显变了，排名靠前的项目共同指向一个关键词：治理。

不再是"我的 Agent 更能写代码"，而是"我的 Agent 更克制、更可审计、更能被组织信任"。这个转变不是偶然的，它是 Agent 从玩具走向生产环境的必经之路。今天我们就把这个风向拆开看看，聊一聊为什么"更克制"反而是更高级的能力。

技术原理：为什么"能干"和"可托付"是两回事

Agent 的核心循环很简单：感知 → 规划 → 行动 → 观察 → 再规划。早期项目把全部精力放在"规划得更聪明"上，但生产环境里真正让 Agent 翻车的，几乎都不是规划错误，而是行动失控：

一个本该只读代码库的任务，顺手执行了 rm -rf
一个改配置的请求，把测试环境的变更推到了生产分支
一个长任务跑崩了，没人知道它中途改了哪些文件

这些问题在 demo 里永远暴露不出来，因为 demo 的任务边界是人盯着的。一旦放进组织流程，每一次无约束的写操作都是一次事故候选。

所以这一波"可治理"项目的共性设计可以归纳为三层：

权限分级：把工具分成只读、低危写、高危写三档，高危操作必须经过显式审批。这和操作系统的权限模型（user/group/other）思路一致------能力不等于授权。
操作留痕：每次工具调用记录"谁、在哪个会话、基于什么上下文、改了什么"，形成可回放的操作日志。出问题时能 diff 回去，而不是靠猜。
门禁校验：在 Agent 输出和实际执行之间插入一层校验，比如对 shell 命令做静态风险扫描，对文件写入做路径白名单匹配。

本质上，这是把传统 DevOps 里"最小权限原则 + 变更审计 + CI 门禁"三件套，移植到了 Agent 的行动层。老经验，新载体。

实战：给 Agent 加一个审批中间件

下面用一个最小可运行的 Python 示例，演示如何给任意 Agent 的工具调用层加"权限分级 + 审批 + 留痕"。核心思路是：不让 Agent 直接触碰工具，而是所有调用必须穿过一个网关。

python 复制代码

import json, time
from enum import Enum
from dataclasses import dataclass, field

class Risk(Enum):
    READ = 0      # 只读：直接放行
    WRITE = 1     # 低危写：记录后放行
    DANGEROUS = 2 # 高危：需人工审批

@dataclass
class ToolCall:
    name: str
    args: dict
    risk: Risk

# 高危命令特征：宁可误报，不可漏报
DANGEROUS_PATTERNS = ["rm -rf", "git push --force", "DROP TABLE", "sudo "]

def classify(call: ToolCall) -> Risk:
    if call.name in ("read_file", "search_code"):
        return Risk.READ
    if call.name == "run_shell":
        joined = json.dumps(call.args)
        if any(p in joined for p in DANGEROUS_PATTERNS):
            return Risk.DANGEROUS
        return Risk.WRITE
    return Risk.DANGEROUS  # 默认从严

audit_log = []  # 生产环境应落库，这里用内存示意

def gateway(call: ToolCall, approver=None) -> dict:
    level = classify(call)
    entry = {
        "ts": time.time(), "tool": call.name,
        "args": call.args, "risk": level.name,
        "status": "executed",
    }
    if level is Risk.DANGEROUS and not approver:
        entry["status"] = "blocked_pending_approval"
        audit_log.append(entry)
        return {"ok": False, "reason": "需要人工审批，已挂起"}
    audit_log.append(entry)
    return {"ok": True, "result": f"<模拟执行 {call.name}>"}

# 演示
print(gateway(ToolCall("search_code", {"q": "main()"}, Risk.READ)))
print(gateway(ToolCall("run_shell", {"cmd": "pytest -q"}, Risk.WRITE)))
print(gateway(ToolCall("run_shell", {"cmd": "rm -rf build/"}, Risk.DANGEROUS)))
# -> 最后一条被拦截挂起，传入 approver 后才可执行

这个网关只有 40 行，但生产级项目（如各家的企业版 Agent）用的正是同样的骨架，差别只在于：审批流转接到了 IM/工单系统、审计日志带完整性校验、高危规则库持续更新。

再补一个最小权限的小技巧------文件写入白名单：

python 复制代码

import fnmatch
ALLOWED_PATHS = ["src/**", "docs/**", "tests/**"]

def path_allowed(path: str) -> bool:
    return any(fnmatch.fnmatch(path, p) for p in ALLOWED_PATHS)

# Agent 想写 .github/workflows/deploy.yml 时直接拒绝，
# 部署配置的变更必须走人工 PR，不给 Agent 留口子。

总结与最佳实践

把今天的观点收敛成几条可落地的建议：

默认从严：classify 函数对未知工具返回最高危级别，白名单思维优于黑名单。
审批即异步：高危操作挂起而不是报错，Agent 继续做能做的事，审批通过后再恢复------别让人等机器，让机器等人。
日志先于功能：先保证每次调用可追溯，再谈能力扩展。出了事故，一份完整审计日志的价值远超多出来的任何功能。
克制是竞争力：给团队选型 Agent 框架时，别只看 demo 炫技，先看它的权限模型、审批接入点和审计能力。

榜单风向已经说明了问题：Agent 开发的下半场，比的不是谁跑得快，而是谁跑得稳、出了事谁说得清。把"可治理"做进架构里，你的 Agent 才有资格进入生产环境。

（全文约 1800 字）