问题的本质

多 Agent 系统在企业落地时，最常见的误区是：先跑起来再说，权限和安全以后补。

但现实是——当 Agent 开始调用数据库、写文件、操作生产系统时，权限设计就不是可选项了，而是生死线。

权限隔离：从共享沙箱到命名空间

最小权限原则

每个 Agent 应该只拥有完成其职责所需的最小权限。这听起来简单，但在 Agent 框架中实现却不容易，因为 Agent 的 Tool 调用往往是动态的——一个对话内，Agent 可能调用 3 个不同的 Tool，每个 Tool 的权限边界不同。

实操方案

1. 命名空间隔离

每个 Agent 运行在独立的逻辑命名空间中，Namespace 决定了：

• 能访问哪些 Tool
• 能读写哪些数据源
• 能调用哪些外部 API

2. RBAC + ABAC 双层校验

• RBAC（角色级）：定义 Agent 的角色（如"只读分析员"、“写操作员”、“管理员”）
• ABAC（属性级）：在每次 Tool 调用时，检查调用者的属性（时间、IP、来源上下文、风险等级）

双层校验的关键在于：RBAC 划定范围，ABAC 做实时决策。单纯 RBAC 会导致权限过粗，单纯 ABAC 则管理成本过高。

3. 人工确认网关

对于涉及敏感操作（如写入数据库、发送邮件、执行命令）的 Tool 调用，设计一个"人工确认"中间层。Agent 发出请求 → 等待人工确认 → 放行或拒绝。这个机制在高风险场景中是不可或缺的，也是用户信任 Agent 的基础。

风险治理：全链路可观测性

护栏模型（Guardrails）

Guardrails 不是简单的关键字过滤，而是部署一个专门的"Agent 监控 Agent"，实时审查：

在实验环境中，我们习惯用准确率（Accuracy）来评判 Agent 的好坏。但准确率在生产环境中几乎没有参考价值——它衡量的是"理想条件下的上限"，而不是"真实环境中的稳态"。

生产级 Agent 的质量评测，核心在于回答三个问题：

• 响应是否流畅？
• 系统是否稳定？
• 用户是否愿意信任并持续使用？

一、响应质量：流式体验与长期一致性

1. 首字延迟 (TTFT - Time To First Token)

这是用户感知最直接的指标。Agent 在收到用户问题后，多长时间输出第一个有效 Token？TTFT 过长（超过 2 秒），用户就会觉得"卡"。

• 目标值：< 500ms（良好），< 1s（可接受），> 2s（需要优化）
• 优化方向：模型推理速度、检索 Pipeline 并行化、缓存层

2. Token 吞吐 (TPS)

TTFT 只关心第一个字，TPS 衡量的是后续生成的流畅度。Agent 在输出长回答时是否一气呵成，还是断断续续？

3. 长对话上下文一致性

这是很多 Agent 的痛点——对话到第五轮、第十轮时，Agent 是否还记得前面说过什么？是否出现了"漂移"或"自相矛盾"？

衡量方法：在对话最后用一组"上下文探查问题"（Probe Questions），检验 Agent 是否还能正确回答前几轮讨论过的内容。

二、系统稳定性：从单次测试到持续监控

1. Tool 调用失败率

Agent 的脆弱性往往不来自模型本身，而来自它调用的 Tool。API 超时、服务不可用、数据格式变更，都能导致 Agent 崩溃。

生产环境中应当持续追踪：

• 各 Tool 的调用成功率
• 调用耗时分布（P50、P95、P99）
• 失败时的 fallback 机制是否触发

2. 异常处理覆盖率

当 Agent 遇到无法处理的输入、工具调用失败、或者模型输出异常时，是否有合理的退路？异常处理覆盖率 = 系统能优雅处理的异常场景数 / 所有已知异常场景数。

计划赶不上变化

前面五篇文章讨论的问题都有相对明确的对策——幻觉可以加 RAG，工具错误可以强 Schema，崩溃可以做检查点，协调可以共享状态，治理可以定规则。但有一个问题是本质性的：未来不可预测，而智能体必须做决策。

这就是规划失效问题：智能体基于当前信息制定了完美的执行计划，但执行过程中环境变了、信息更新了、前提不成立了——计划从"最优解"变成了"最蠢路径"。

这不是 AI 的特殊问题，是人类也在天天面对的。区别在于人类有丰富的经验来应对不确定性，而智能体的"经验"只有训练数据和当前上下文。

不确定性的三个来源

来源一：环境动态性

外部环境在 Agent 执行任务期间发生了变化。

典型场景

Agent 计划：查库存 → 下单 → 发货
现实发生：查库存时有货 → 下单时库存已变（另一位客户买了）→ 发货失败

动态环境中的"信息时效性"问题：

• 查询时信息准确 ≠ 行动时信息准确
• 信息和行动之间的时间差越大，规划越可能失效
• 有些环境变化不可预测（突发需求、系统故障、外部政策调整）

特殊难点：Agent 自身改变了环境

Agent 的行动可能改变了它所处环境的条件，导致后续计划的前提不再成立：

Agent 分析了市场数据 → 基于分析推荐了 A 股票
→ 1000 个用户跟随买入 → A 股价被推高
→ Agent 原有的"低估"判断不再成立

这就是反身性（Reflexivity）——观察行为本身改变了被观察对象。 Soros 讲了几十年的金融哲学，在 Agent 时代以新形态重现。

来源二：信息不完备性

Agent 做决策时所依据的信息不完整。

已知的不确定 vs 不确定的不确定

• 已知的不确定：Agent 知道自己不知道什么。比如"我不知道今天的库存量，需要先查询"
• 不确定的不确定：Agent 不知道自己不知道什么。比如 Agent 以为自己了解退货政策，但政策上周刚改了，它不知道

后者更危险——Agent 在错误的前提下做出自信的决策，和幻觉类似但根源不同：幻觉是模型编造事实，信息不完备是真实事实缺失但 Agent 假装拥有。

隐性约束

很多约束没有写在文档里，是行业惯例或组织内部的不成文规则：

智能体的"半途而废"之痛

写代码的人都知道——程序崩溃不可怕，可怕的是崩溃后状态全丢，只能从头再来。

智能体面临的就是这个问题。一个 20 步的自动化任务，执行到第 15 步时 LLM API 超时了，所有中间状态消失。下次运行从第 1 步重新开始，前面的 14 步白做了。如果有副作用（已经发了一封邮件、已经创建了一条数据库记录），那就更麻烦——重做会导致重复操作。

Temporal 的技术博客 2026 年 4 月发表了一篇引起广泛共鸣的文章，核心观点是：AI 可靠性是一个十年前就该解决、现在仍然只解决了一半的问题。我们应该用基础设施手段而非更好模型来解决它。

为什么智能体会中途崩溃？

原因一：LLM 推理本身就是不稳定的

传统软件的执行路径是确定性的——给定相同输入，永远走同一条路。LLM 不是。每一次推理都是一次概率采样，天生带有不确定性：

• API 超时：模型推理慢时，HTTP 请求可能超时中断
• Token 限制：上下文窗口满了，前面的轮次被截断
• Rate Limit：API 调用频率受限，被 429 返回
• 服务降级：高峰期模型响应质量下降
• 随机中断：GPU 集群节点切换、负载均衡导致连接中断

这些问题不是偶尔发生的，在大规模生产环境中是常态。

原因二：智能体状态是"内存态"的

大多数 Agent 框架把执行状态存在内存中：

# 典型的 Agent 循环
state = initial_state
for step in plan:
    state = llm_call(step, state)  # state 在内存
    state = tool_call(step, state)  # 一旦进程挂了，state 全丢

传统软件有数据库保驾护航——应用挂了重启后数据还在。Agent 框架呢？进程一死，所有中间推理、工具返回、上下文积累全部消失。

原因三：长链路任务的脆弱性

智能体任务越复杂，包含的步骤越多，执行成功率呈指数下降：

单步成功率 95%
10 步任务成功率: 0.95^10 = 59.9%
20 步任务成功率: 0.95^20 = 35.8%
50 步任务成功率: 0.95^50 = 7.7%

即使每步有 95% 的成功率（这已经是优秀的表现），一个 20 步任务就有近 2/3 的概率在某步失败。而大多数真实业务场景不止 20 步。

一个人干不了所有活

单个智能体再强，也有能力边界。它不可能同时是代码专家、财务分析师、法律顾问和设计师。于是多 Agent 协作成为自然选择——让不同专长的 Agent 各司其职，协同完成复杂任务。

听起来很美好，实战中却是一地鸡毛。

Medium 上有一篇被广泛引用的文章，标题就很直白：《Multi-Agent AI 的黑暗心理学：30 种能摧毁你整个系统的失败模式》。30 种可能是夸张了，但核心观点不虚——多 Agent 系统的复杂度不是线性增长，而是指数增长。2 个 Agent 的协调问题比 1 个 Agent 多不止一倍。

三种协作架构

先理清多 Agent 协作有哪几种模式，再分析各自的问题。

模式一：Orchestrator-Worker（中心调度）

一个"主管" Agent 负责理解任务、分解子任务、分派给专业 Worker Agent，最后汇总结果。

[Orchestrator] → 分派 → [代码 Agent]
              → 分派 → [财务 Agent]
              → 分派 → [设计 Agent]
              ← 汇总 ← 各 Agent 结果

优点：逻辑清晰、责任划分明确 缺点：Orchestrator 成为单点瓶颈——它既要理解全局，又要管理分发，还要处理冲突

模式二：Pipeline（流水线）

Agent 按照固定顺序串联执行，前一个的输出是后一个的输入。

[需求分析 Agent] → [设计 Agent] → [编码 Agent] → [测试 Agent] → [部署 Agent]

优点：简单、可预测 缺点：无反馈回路——如果测试 Agent 发现问题需要返回设计阶段，流水线很难回溯

当智能体的"手"不听使唤

如果说幻觉是智能体"脑子"的问题，那工具调用失败就是"手脚"的问题。智能体不仅要思考，还要行动——调用 API、查询数据库、操作文件系统。而但凡涉及外部系统交互，失败的维度比纯文本幻觉要多得多。

Arize AI 2026 年对生产环境智能体的故障分析指出：工具相关失败占 Agent 异常的 40% 以上，其中最危险的不是"调用失败"本身，而是失败后的错误处理——智能体对错误的理解和处理能力，往往比工具调用本身更不可靠。

三大失败模式

模式一：静默错误——最危险的失败

工具返回了错误信息，但智能体没有正确解读，把错误响应当做正常结果继续推理。

典型场景

// 智能体调用天气 API
{"tool": "get_weather", "arguments": {"city": "北京", "date": "2026-07-01"}}

// API 返回错误
{"error": "city_not_found", "message": "City name must be in English: Beijing"}

// 智能体把 json 当成了天气数据继续推理
"根据返回的数据，北京7月1日的湿度和 error 字段显示..."

这比调用直接报错更危险——至少报错时智能体知道出错了，还能重试。静默错误时，智能体浑然不知，把垃圾数据当成金子继续加工。

为什么会发生？

1. 错误格式不统一：不同 API 的错误响应结构不同（HTTP 状态码、JSON error 字段、HTML 错误页……），智能体难以用统一逻辑识别
2. Prompt 缺少错误处理指令：很多人在 system prompt 里只写了"使用 XX 工具查询"，没写"如果工具返回错误，你应该……"
3. 模型倾向"继续完成任务"：遇到异常数据时，模型的训练倾向是给用户一个答案，而不是停下来讨论 API 报错

模式二：参数构造错误——最常见的失败

智能体理解了要调什么工具，但构造参数时出错。

常见错误类型

• 格式错误：日期传 2026/07/01 而 API 要 2026-07-01
• 类型错误：传字符串 "5" 而 API 要整数 5
• 枚举错误：传 "medium" 而有效值只有 ["low", "mid", "high"]
• 遗漏必填参数：忘了传 currency 字段
• 语义错误：传了合法格式但语义不对，比如把 page_size=100 传给了限制最大 50 的分页接口

根因分析

模型对 API 的理解来自 prompt 中的工具描述（Function Schema）。如果描述不够精确——比如某个参数的合法值只写了 string 没有枚举——模型就只能"猜"。

幻觉：智能体最顽固的问题

如果只能用一个词概括当前 AI 智能体最致命的问题，行业里多数人会选"幻觉"（Hallucination）。通用大模型写诗写周报文采斐然，但让它分析"上季度 A 产品线毛利率下降的原因"，它可能编造一串子虚乌有的数据，还附上看起来很专业的百分比。更糟糕的是——语气越自信，越难被非专业用户识破。

Fiddler AI 2026 年的报告给出了一个残酷的数字：生产环境智能体失败率 70%-95%，幻觉是头号杀手。BetterYeah 的调研发现，68% 的企业在 AI 落地中遭遇幻觉问题，其中 32% 因错误累积导致系统性风险。

这不是"模型还不够聪明"的问题。这是智能体的结构性挑战。

从单步错误到幻觉累加

单步幻觉：模型不确定时仍"自信输出"

LLM 的核心训练目标是"合理续写"，而不是"如实回答"。当训练数据中缺少相关信息时，模型不会说"我不知道"——它会生成一段看起来连贯但实际上没有事实支撑的文字。

这是因为：

1. 训练数据偏差：互联网文本中，自信断言远多于谦虚声明"我不确定"
2. 采样机制：模型采样概率最高的 token 序列，不受事实约束
3. 缺乏不确定性建模：模型内部没有显式的"置信度"信号传递给输出层

结果：模型在信息不足时的行为是"编造"，而非"沉默"。

多步累加：小偏差滚雪球

当智能体执行多步任务时，单步幻觉的破坏力被指数放大。看一个典型场景：

步骤 1：检索客户信息 → 幻觉：编造了不存在的客户 ID
步骤 2：用该 ID 查询订单 → 返回空结果
步骤 3：智能体"推断"该客户是新客户 → 编造注册时间
步骤 4：基于虚假注册时间做客户画像分析 → 输出错误结论
步骤 5：基于错误结论撰写运营建议 → 决策偏离

每一步都"合乎逻辑"，但起点就是一个虚构的事实。这就是幻觉累加效应——错误在推理链中不断传播和放大，最终输出和现实南辕北辙。

2025 年 Q1 某金融机构的案例就是典型：智能体在财报分析中第一次幻觉了一个营收数字，后续所有财务比率、趋势判断、投资建议全部基于这个错误数字展开。表面看报告专业完整，实际结论完全失真。

为什么传统 NLP 时代的幻觉没那么致命？

传统 QA 系统也幻觉，但影响范围有限——一次问答的错误不影响下一次。智能体截然不同：它是一个持续运行的闭环系统，前一步的输出是后一步的输入。一个幻觉 token 就像生物学中的基因突变，在后续"转录"过程中被不断放大。

三类幻觉的根源

1. 事实性幻觉

模型编造不存在的事实。典型表现：

当智能体有了"自主权"，谁为它的行为负责？

前几篇文章讨论的问题——幻觉、工具调用失败、崩溃、协调混乱——都是技术可解的。但有一类问题超越了技术范畴：当智能体越来越多地代替人做决策和行动时，谁来为后果负责？

McKinsey 2026 年 AI 信任成熟度调研覆盖了数千家企业，核心发现是：企业对 AI 的信任没有跟上 AI 能力的增长。随着 Agent 从"辅助工具"走向"自主行动者"，治理和问责缺位成了最紧迫的系统性风险。

这不是"以后再考虑"的问题。2025 年已经有多起因 AI Agent 自主行动导致的业务事故：

• 客服 Agent 自作主张给用户全额退款
• 营销 Agent 向错误人群发送敏感促销
• 数据处理 Agent 把内部数据写入了外部系统

每一件事的直接原因都是技术层面的（幻觉、工具错误），但根本原因是治理框架缺失——没有人为 Agent 的行动设定边界。

四大治理挑战

挑战一：权限边界模糊

核心问题

智能体能干什么？哪些决策它可以自己做？哪些必须请示？

大多数 Agent 系统根本没有清晰定义权限边界。系统 prompt 里写了"帮用户处理订单"，但没有写：

• 你可以取消订单吗？
• 你可以修改价格吗？
• 你可以给超过 100 元的订单退款吗？
• 你可以查看其他用户的数据吗？

为什么重要

权限不清时，Agent 的两种倾向都会出问题：

• 过度谨慎：什么都问用户，失去自动化的意义
• 过度激进：什么都自己做，出了事不可控

现实中的 Agent 往往走向后者——因为"帮用户解决问题"的指令天然偏向行动，而非克制。

类别

权限至少需要从三个维度定义：

1. 数据维度：能访问什么数据？能读哪些？能写哪些？
2. 操作维度：能执行哪些操作？取消订单 vs 修改地址 vs 查看物流？
3. 金额维度：操作有财务影响时，上限在哪里？

挑战二：审计追踪缺失

核心问题

Agent 做了一个决策，事后能否完整回溯"它为什么这样做"？

目前多数 Agent 系统的回答是：不能。

• 推理过程只存在于 LLM 的上下文中，运行结束后消失
• 工具调用的参数和返回值可能记录了，但"为什么选择调这个工具"没有记录
• 多步推理中，前面步骤的中间结论影响了后面决策，但这些因果链没有被显式记录

后果

没有审计追踪 = 没有问责基础。

从 luck-agent 到 Hermes-lite，我花了两年时间才想清楚这个问题：80% 的请求不需要"思考"，只需要"路由"。

回顾：ReAct 控制器模式的困境

2024 年做 luck-agent 的时候，我采用的是经典的 ReAct 模式（Reasoning + Acting）：

用户输入 → 大模型推理（意图识别 → 规划 → 工具选择 → 执行）→ 输出

所有请求，不管简单还是复杂，都走同一个推理链。一个"查 QPC 里有没有 VPS 相关的记录"的请求，也要经过：

1. 理解自然语言
2. 判断意图类别
3. 选择工具（search_qpc）
4. 构造查询参数
5. 执行并解释结果

问题很明显：

• Token 消耗大：每次推理要带上完整的 system prompt + 工具定义，光上下文就吃掉 3000-5000 token
• 延迟高：一个简单查询要等模型完成完整推理链，响应时间 3-8 秒
• 上下文窗口压力：随着工具数量增加（现在 Hermes-lite 有 20+ 个工具），system prompt 越来越大

我当时就在知识库里记了一条：

“对于个人助理场景，相比最初的 ReAct 控制器模式，Skill 技能路由更适合当前 luckagent：80% 请求是固定模式，不需要复杂推理，技能比 Agent 更稳定，成本更低，响应更快。”

Skill 路由的核心思想

一句话：预定义技能映射，轻量分类先路由，只加载需要的工具和 prompt。

用户输入 → 轻量路由（关键词/意图 → 技能）→ 加载专用 prompt + 工具 → 执行

路由表设计

# 简化版路由逻辑
ROUTING_RULES = {
    "qpc": {
        "keywords": ["QPC", "知识库", "记一下", "记录"],
        "skill": "qpc",
        "tools": ["feishu_bitable_read", "feishu_bitable_write"],
        "prompt": "qpc_skill_prompt"  # 只加载 QPC 相关的 prompt
    },
    "vps": {
        "keywords": ["VPS", "服务器", "防火墙", "Docker"],
        "skill": "gcp-vps-ops",
        "tools": ["terminal", "read_file"],
        "prompt": "vps_skill_prompt"
    },
    "blog": {
        "keywords": ["博客", "文章", "Hugo", "发布"],
        "skill": "hugo-blog",
        "tools": ["terminal", "read_file", "write_file"],
        "prompt": "blog_skill_prompt"
    }
}

对比：同样"查 QPC"操作

Hermes-lite 的 Skill 实现

Hermes-lite 的 skill 系统是这样工作的：

试过 Obsidian 的标签体系、Notion 的数据库、Logseq 的 graph view，最后发现：知识库的最大敌人不是容量，是维护摩擦。

为什么不做"完美知识库"？

我曾经是一个"知识管理完美主义者"。

尝试 1：Obsidian + 标签体系 + 双向链接

每个笔记文件：
- 标签：#python #async #bug-fix #2026-06
- 链接：[[python-async]] [[common-bugs]]
- 元数据：create_date, last_modified, status, project

结果：三个月后标签体系崩溃了。#python 和 #Python 是两个标签，#bug-fix 和 #bugfix 也是。双向链接变成死链接（文件删了链接还在）。维护成本爆炸，写一条笔记要先想该打什么标签——思考的 friction 超过了记忆的 friction。

尝试 2：Notion 数据库 + 多字段

数据库字段：标题、类型（6 种）、标签（多选）、项目、优先级、状态、来源、日期、附件、笔记

结果：90% 字段闲置。每次新建记录，11 个字段只填 2-3 个，其余空着。Notion 还要求你手动选"类型"、拖"优先级"——录入摩擦太高，最后只记录了 30 条就放弃了。

核心洞察

知识管理的杠杆 = 写入 × 重读，不是字段数。

如果写入摩擦太高，你就不写。如果字段太多、标签太复杂，你就不维护。极简设计 = 更低的维护摩擦 = 更长的生命周期。

QPC 的 4 字段设计哲学

我的 QPC（Question / Practice / Concept）知识库现在有 199 条记录，只用 4 个字段：