Skip to content

3.1 六层架构模型

引言:六个科室的医院

五个问题就像五个病人,现在看 Harness 这个"医院"的六个科室。

前两节我们诊断了 Agent 在生产环境中的五大顽疾——幻觉、工具失败、上下文溢出、权限失控、级联故障。这些不是孤立的 bug,而是系统性的架构缺陷。

核心认知

Harness Engineering 不是"给 Agent 加个护栏",而是用六层架构把不确定性逐层过滤,让 Agent 在安全边界内自由行动。


问题 → 架构映射

1幻觉与编造L2 验证与确认输出必须可校验
2工具调用失败L1 信息边界约束工具的输入输出范围
3上下文溢出L3 上下文管理主动裁剪、摘要、分区
4权限失控L4 权限与审计最小权限 + 分层授权
5级联故障L5 级联防护 + L6 恢复与治理隔离故障域 + 自动回滚

六层架构详解

L1信息边界
Agent 看到什么、能说什么
输入过滤输出约束工具 schema 限定
L2验证与确认
输出是否可靠
Schema 校验人工审批双重检查
L3上下文管理
长任务中记忆与注意力的衰减
滑动窗口摘要压缩分区隔离
L4权限与审计
Agent 能做什么、做了什么
RBAC操作日志审批流
L5级联防护
一个 Agent 坏了不拖垮全局
熔断器超时重试预算
L6恢复与治理
出事后怎么恢复、怎么改进
快照回滚事后复盘持续改进

L1 信息边界——定义 Agent 的"视界"

Agent 只能基于它看到的信息做决策。控制输入,就控制了决策质量的下限。

  • 输入过滤:去掉无关信息、注入必要约束
  • 输出约束:用结构化 schema 限制 Agent 的返回格式
  • 工具 schema:精确描述每个工具的参数、类型、边界

L2 验证与确认——不相信,要验证

Agent 的输出必须经过校验才能生效。这是"信任但要验证"原则的工程化。

L3 上下文管理——注意力是稀缺资源

LLM 的上下文窗口有限,长任务中信息会丢失。主动管理上下文,比被动等待溢出要好得多。

L4 权限与审计——最小权限 + 全程留痕

每个 Agent 只拥有完成当前任务所需的最小权限,所有操作全程记录。

L5 级联防护——不让局部故障变成全局灾难

多 Agent 系统中,一个 Agent 的失败可能通过调用链传播。熔断器和超时是第一道防线。

L6 恢复与治理——出事后的兜底方案

即使前五层都防不住,第六层保证系统可以快速恢复,并从故障中学习。


优先级建议

P0立刻做
1L1 信息边界没有边界,其余一切无从谈起
2L2 验证与确认不验证的 Agent 输出 = 定时炸弹
3L4 权限与审计权限失控是生产事故的第一大诱因
P1之后做
4L5 级联防护多 Agent 场景下必须,单 Agent 可暂缓
5L3 上下文管理短任务可能不需要,长任务必不可少
6L6 恢复与治理需要一定积累才有数据改进
7L3 + L5 联动上下文溢出本身就是级联故障的常见触发器
P2有余力做
8跨层监控仪表盘可视化六层指标
9自动化故障演练Chaos Engineering for Agents
10六层成熟度评估建立评分体系,持续改进

本节小结

📌 本节核心要点

  • 五大痛点对应六层架构,每层解决一类不确定性
  • L1-L3 偏"预防",L4-L6 偏"控制与恢复"
  • 优先级:先做信息边界和验证(P0),再做防护和治理(P1/P2)
  • 六层不是孤立存在,层与层之间有联动关系

思考题

  1. 你当前项目中的 Agent,哪一层最薄弱?如果那一层失守,最坏后果是什么?
  2. L1 信息边界和 L4 权限与审计有什么区别?它们分别防止什么类型的问题?
  3. 如果只能先实现两层,你选哪两层?为什么?

下一节预告

架构设计好了,首先得给 Agent 合适的工具——工具设计是 Harness 的第一块砖。

下一节:工具设计模式