"人做主，AI做事" — 我的 AI Agent 团队管理哲学

我运营着一个 8 人的 Agent 团队。不是 8 个人，是 8 个 AI Agent。它们帮我同时支撑三条业务线：ArkTop AI 的客户报告、JewelFlow 的用户运营、一人独角兽俱乐部的社群管理。

去年我花了 $6,400 在 LLM API 调用上，省下来的是大约 1,200 小时的执行型工作。但这个结果不是靠堆 Agent 数量得来的。中间走过一段弯路——让 Agent 做太多决策，结果客户收到了一封不该发的邮件，我花了一整个下午在道歉。

那次事故之后，我把自己的 Agent 管理方法论重新梳理了一遍，提炼成一句话：人做主，AI 做事。这篇文章把这个哲学拆开讲，包括背后的决策边界模型、实现方式、和踩过的坑。

---

为什么需要一套管理哲学

很多人搭 Agent 的思路是：把任务描述清楚，丢给 LLM，让它自己跑。简单任务没问题。但一旦 Agent 数量超过 3 个、涉及多个业务流程，问题就开始暴露：

问题一：Agent 之间的决策冲突。 我的内容 Agent 认为某个话题应该发，但排期 Agent 认为这周已经满了。谁说了算？没有明确的决策权归属，两个 Agent 会陷入死循环或者各自输出矛盾结果。

问题二：隐性决策溢出。 你让 Agent 写一封跟进邮件，它"顺便"决定了跟进的时间、语气、和是否附上报价单。你以为它只做了执行，其实它做了四个决策。

问题三：出错时无法溯源。 当系统出问题，你不知道是哪个 Agent 在哪一步做了错误判断。没有决策审计，debug 全靠猜。

这三个问题的本质是同一个：你没有定义清楚哪些事需要人类判断，哪些事可以交给 Agent 自主执行。

---

核心框架：三层决策边界模型

我把所有 Agent 可能涉及的操作分成三个层级：

第一层：Agent 完全自主（绿区）

这些操作的特征是：可逆、低风险、有明确标准。

• 数据格式转换
• 内部文档整理和分类
• 定期报告生成（基于已审核的模板）
• 社群常见问题自动回复

绿区内，Agent 不需要请示，直接执行。错了也好修，成本低。

第二层：Agent 执行 + 人类审批（黄区）

这些操作的特征是：对外可见、涉及金额、或者影响客户体验。

• 发送客户邮件
• 社群公告发布
• 产品定价调整建议
• 内容发布到社交媒体

黄区内，Agent 完成草稿或者准备好操作，但必须等人类确认才能执行。

第三层：纯人类决策（红区）

这些操作的特征是：不可逆、高利害关系、需要上下文判断。

• 合作伙伴关系谈判
• 客户投诉升级处理
• 业务战略方向调整
• 任何涉及法律或合规的决定

红区内，Agent 的角色是提供信息和分析，但决策权完全在人类手上。

代码实现：决策边界检查器

from enum import Enum
from dataclasses import dataclass

class DecisionZone(Enum):
    GREEN = "autonomous"    # Agent 完全自主
    YELLOW = "supervised"   # Agent 执行，人类审批
    RED = "human_only"      # 纯人类决策

@dataclass
class Action:
    name: str
    zone: DecisionZone
    reversible: bool
    external_facing: bool
    financial_impact: float  # 涉及金额，单位美元

# 决策边界规则引擎
def classify_action(action_name: str, context: dict) -> DecisionZone:
    """根据操作特征自动分类决策层级"""
    rules = {
        "external_facing": DecisionZone.YELLOW,  # 对外可见 → 至少黄区
        "financial_impact_over_100": DecisionZone.YELLOW,
        "financial_impact_over_1000": DecisionZone.RED,
        "irreversible": DecisionZone.RED,
        "legal_compliance": DecisionZone.RED,
    }

    zone = DecisionZone.GREEN  # 默认绿区

    if context.get("external_facing"):
        zone = max(zone, DecisionZone.YELLOW, key=lambda z: z.value)
    if context.get("financial_impact", 0) > 100:
        zone = DecisionZone.YELLOW
    if context.get("financial_impact", 0) > 1000:
        zone = DecisionZone.RED
    if not context.get("reversible", True):
        zone = DecisionZone.RED

    return zone

# Agent 执行前的守门检查
class DecisionGate:
    def __init__(self, human_approver):
        self.human_approver = human_approver
        self.audit_log = []

    async def check(self, agent_id: str, action: Action) -> bool:
        """执行前检查：绿区直接过，黄区等审批，红区拒绝"""
        self.audit_log.append({
            "agent": agent_id,
            "action": action.name,
            "zone": action.zone.value,
            "timestamp": datetime.now().isoformat()
        })

        if action.zone == DecisionZone.GREEN:
            return True
        elif action.zone == DecisionZone.YELLOW:
            return await self.human_approver.request_approval(action)
        else:
            return False  # 红区操作 Agent 不允许执行

这段代码的核心思想：每个 Agent 操作在执行前必须过一道 gate，gate 根据操作的分类决定放行、等待审批、或者拒绝。 同时所有操作都写入 audit log，出问题可以回溯。

---

实战经验：这套系统是怎么长出来的

那封不该发的邮件

2025 年 6 月，我的客户跟进 Agent 发了一封邮件给一个正在谈合作的潜在客户，内容是标准的项目提案模板。问题是：这个客户前一天刚跟我说他们内部在重组，暂时搁置所有新项目。Agent 不知道这个上下文，按照自动化流程照常发了。

客户的反应是："你们是不是没在听我说话？"

这封邮件本身没有错误，模板是对的，时间是预设的。错的是 Agent 做了一个它没有能力做的判断：现在是不是发这封邮件的合适时机。

从那以后，所有对外通信都从绿区移到了黄区。Agent 草拟完邮件，推送到我的审批队列，我用不超过 30 秒扫一眼确认。效率只降了一点点，但风险降了一个数量级。

审批疲劳的陷阱

把太多东西放进黄区也有问题。一开始我矫枉过正，几乎所有操作都要我审批。结果每天早上打开 Slack 有 40 多条审批请求，我开始机械地点"批准"，根本没认真看内容。这跟没有审批是一样的。

后来我做了两个调整：

第一，收紧绿区的定义，但让绿区内的操作真正自由。 比如社群常见问题回复，我花了两天整理了 200 条标准答案，Agent 在这个范围内可以完全自主。

第二，黄区审批做分级。 高优先级（涉及客户或金额）推送 Slack 即时通知，低优先级（社群内容排期）每天汇总一次，我统一审批。批量处理比逐条处理快得多。

调整后，日均审批从 40 多条降到 8-10 条，每条花 15-30 秒，总共不超过 5 分钟。

决策权下放是渐进的

我刚开始搭 Agent 系统时，几乎所有操作都在红区。随着对每个 Agent 的能力边界越来越清楚，我逐步把操作往绿区迁移。

这个过程像带新人：你不会第一天就让新员工独立见客户。你先让他旁听，再让他在你监督下做，最后才放手。AI Agent 也一样，只是"带"的过程更快——通常两三周就能确定一个操作的安全边界。

---

人类监督的设计模式

模式一：异步审批队列

Agent 完成黄区任务后推入队列，人类在方便的时候集中处理。适合时效性要求不高的操作，比如内容排期、周报发送。

模式二：实时拦截

Agent 在执行前实时等待人类确认。适合时效性高且风险高的操作，比如客户紧急回复、支付操作。延迟在 5 分钟以内可以接受。

模式三：事后抽检

Agent 自主执行，但系统随机抽取一定比例（我设的是 10%）的操作推给人类复查。适合从黄区刚降级到绿区的操作——你对它有一定信心，但还想保持监控。

import random

class OversightPattern:
    """三种人类监督模式的实现"""

    def __init__(self, sample_rate: float = 0.1):
        self.approval_queue = []
        self.sample_rate = sample_rate

    async def async_approval(self, action, agent_output):
        """模式一：异步审批 — 推入队列等人类处理"""
        self.approval_queue.append({
            "action": action,
            "output": agent_output,
            "status": "pending"
        })
        # 不阻塞 Agent 继续其他绿区任务

    async def realtime_gate(self, action, agent_output):
        """模式二：实时拦截 — 等人类确认才放行"""
        approval = await self.notify_and_wait(action, agent_output)
        return approval  # True 放行，False 驳回

    async def post_hoc_sampling(self, action, agent_output):
        """模式三：事后抽检 — 先执行，随机抽查"""
        # 先执行
        result = await self.execute(action, agent_output)
        # 按比例抽检
        if random.random() < self.sample_rate:
            await self.flag_for_review(action, agent_output, result)
        return result

---

对比：常见 Agent 管理方式的优劣

管理方式	适合场景	风险	效率
完全自主（无监督）	内部低风险任务	高：出错无兜底	最高
每步审批	高利害关系的初期项目	低	最低（审批疲劳）
三层决策边界	多 Agent 长期运行的业务系统	中低：风险分级控制	高：只审关键操作
结果审计（事后）	大量标准化输出	中：发现问题有延迟	高

我的建议是：起步用"每步审批"，运行两周后切换到"三层决策边界"，对成熟的操作逐步引入"事后抽检"。

---

这个哲学的边界在哪

"人做主，AI 做事" 不是适合所有场景的。

它适合： 个人或小团队运营多条业务线、Agent 数量在 3-15 个之间、操作类型多样的场景。这是大多数 Solopreneur 和小型咨询公司的情况。

它不适合： 需要毫秒级响应的实时系统（交易算法、自动驾驶），因为人类审批会引入不可接受的延迟。也不适合纯研究探索场景——如果你就是想让 Agent 自由探索看看会发生什么，加太多边界会限制它的创造力。

---

三条核心 Takeaway

第一，定义清楚哪些是决策、哪些是执行。 大多数人搭 Agent 时不做这个区分，结果 Agent 在"执行"的过程中偷偷做了很多决策。每个操作上线前，花 5 分钟想清楚它属于绿区、黄区、还是红区。

第二，监督的成本必须低于不监督的风险。 如果审批流程让你每天花 2 小时，那监督系统本身就是问题。好的监督是轻量的、分级的、可批量处理的。

第三，决策权下放是挣来的，不是给的。 新 Agent、新操作，一律从严开始。跑顺了再放权。信任需要数据支持，不是直觉。

你的 Agent 系统有没有遇到过"它自己做了一个你没想到的决策"的情况？那个时候你是怎么处理的？