业务 Agent 增强层架构：复用通用 Agent 基座，把业务能力做成可验证增强层¶

Ch09.008 业务 Agent 增强层架构：复用通用 Agent 基座，把业务能力做成可验证增强层¶

📊 Level ⭐⭐ | 27.0KB | entities/business-agent-augmentation-layer-practitioner-methodology-20260606.md

概述¶

AI 小老六（WeChat MP）2026-06 提出的 业务 Agent 落地方法论——核心论点：不要重复造通用 Agent，而是把通用 Agent 基座（Codex / Claude Code）当现成基座，业务团队精力集中在补"业务能力增强层"：业务知识 / 内部工具 / 流程规则 / 权限边界 / 评测集 / 线上观测。文章用 3 张判断表 + 1 张能力分工表 + 1 张 6 步执行协议 + 1 份 YAML 配置范例 给出一线团队可立刻照搬的 MVP 落地路径——核心是"跑裸基座 baseline → 补短板 → MVP 闭环 → 增量评测"三步法。

第一性原理：通用 Agent 已经在做的，团队不要重做¶

通用 Agent 擅长的 vs 团队要补的（6 维能力分工表）¶

关键洞见：业务 Agent 失败的根因 90% 不是模型笨，而是边界混乱——通用 Agent 已经会读代码 / 拆任务 / 调工具 / 根据观察调整路线，团队要补的是它不可能天然知道的东西（业务知识 + 内部工具 + 流程约束）。

一句话总结取舍¶

不要让团队去维护一个"比 Codex 更懂代码、比 Claude Code 更会工具调用"的大系统。更有价值的是让通用 Agent 更懂当前团队，能看到内部系统，并且知道什么时候必须停下来。

立项前判断链：跑裸基座 → 看真实能力 → 决定补什么¶

三步立项方法（强烈推荐）¶

1. 跑裸基座 baseline（10-30 个真实 case）：工单 / 告警 / 代码修改 / 发布检查 / 配置排查
2. 判断短板：如果裸基座已经能做 60% → 围绕 40% 短板做增强；如果裸基座在关键任务完全失效 → 先定位是缺业务背景 / 缺工具 / 缺流程约束 / 还是安全边界不允许
3. 决定是否自研：只有少数场景值得自研专项 Agent——强私有化 / 极端时延 / 成本约束 / 通用 Agent 无法接入的封闭运行时 / 必须深度嵌入业务系统的强流程任务 / 合规不允许把任务交给现有基座——除此之外先复用

任务筛选判断表（4 个评估项）¶

作者推荐优先选场景：Oncall 排障 / 发布前检查 / 代码迁移 / 灰度回归 / 数据修复辅助——有明确入口 + 证据来源，Agent 不需要凭空发挥。

增强层架构：6 层职责明确分工¶

┌──────────────────────────────────────────────┐
│ 业务入口层：飞书机器人 / Web / CLI / 工单     │
├──────────────────────────────────────────────┤
│ 知识与上下文层：SOP / 历史案例 / 仓库规则     │
├──────────────────────────────────────────────┤
│ 工具能力层：MCP Server / CLI / OpenAPI        │
├──────────────────────────────────────────────┤
│ 流程编排层：任务模板 / 审批点 / 人工确认      │
├──────────────────────────────────────────────┤
│ 安全治理层：读写分离 / 最小权限 / dry-run     │
├──────────────────────────────────────────────┤
│ 评测观测层：baseline 对比 / 回归集 / trace     │
├──────────────────────────────────────────────┤
│       通用 Agent 基座（Codex/Claude Code）   │
└──────────────────────────────────────────────┘

各层建设重点¶

核心判断：第一版不必做完整平台——选一个真实场景，接入最小知识集和最小工具集，跑通闭环，再决定要不要服务化。

MVP 闭环：6 问清单 + 6 步执行协议¶

MVP 至少要回答的 6 件事¶

1. 选哪个基座：明确使用 Codex / Claude Code 或同类 Agent，并记录裸跑结果
2. 任务怎么进来：写清输入 / 目标 / 约束 / 输出结构 / 停止条件
3. 知识怎么给：先接 SOP / 关键文档 / 历史案例 / 仓库规则
4. 工具怎么接：只接 3-5 个高价值工具，优先读操作和低风险动作
5. 风险怎么控：写操作 / 权限变更 / 外部通知 / 删除必须人工确认
6. 效果怎么评：每次真实任务尽量沉淀成 case，进入回归集

6 步执行协议（Read-Plan-Act-Observe-Gate-Finish）¶

1. Read：先读任务输入、业务知识和必要上下文
2. Plan：给出短计划，说明需要哪些证据和工具
3. Act：调内部工具取证，参数来源必须能在上下文里追到
4. Observe：读工具返回，保留支持假设和推翻假设的证据
5. Gate：写操作 / 权限 / 通知 / 删除必须请求人工确认
6. Finish：交付结论 / 证据 / 置信度 / 仍缺的信息 / 下一步建议

关键：执行循环不要急着自研——团队更该定义的是通用 Agent 执行任务时必须遵守的协议。

配置范例：business_agent_profile YAML¶

business_agent_profile:
  profile_name: lark_oncall_helper
  base_runtime: codex_or_claude_style_agent
  mission: |
    结合工单、群聊和服务资料，给出候选根因、证据和后续排查动作
  run_rules:
    - 优先读取工单上下文、服务 SOP 和近期变更
    - 结论必须附带日志、发布、代码、配置或历史案例证据
    - 证据不足时明确说明缺口，不把猜测写成结论
  context_sources:
    - runbook_by_service
    - incident_case_library
    - repository_owner_map
    - release_and_rollback_notes
  tool_surface:
    mcp_servers:
      - log_query
      - release_change
      - code_search
      - config_query
    cli_tools:
      - test_runner
      - deploy_status
  control_policy:
    max_steps: 12
    stop_and_confirm:
      - write_operation
      - permission_change
      - external_notification
    final_report: conclusion_with_evidence_and_next_action
  evaluation:
    compare_to: plain_base_agent
    case_suite: oncall_regression_set_v1
    release_bar: pass_rate_at_least_90_percent

配置文件的关键："它要让 Agent 知道边界、证据来源和交付格式，而不是把业务流程写成一堆死板分支"——配置文件不需要复杂，关键是结构化、可机器读、可评测。

知识库：不是资料仓库，是给 Agent 用的判断材料¶

知识库最容易做偏的陷阱¶

把所有文档搬进去，最后检索命中一堆长文，Agent 看似"有上下文"，实际仍然找不到能支撑判断的证据。更好的切入点是问题清单——先看 Agent 经常错在哪里，再反推要沉淀什么知识。

5 类 Agent 典型缺口 → 需要沉淀的知识¶

知识块元数据：不要省¶

关键洞见：没有 owner / 更新时间 / 适用范围和证据来源的知识，迟早会变成噪音。知识库接入也不只有 RAG——稳定且必须遵守的规则适合写进 Workspace Rules；实时数据应该走工具查询；历史工单和事故复盘更适合做案例库；用户偏好和服务习惯可以进入长期记忆，但写入门槛必须高。

工具设计：让 Agent 少猜参数，少猜结果¶

知识 vs 工具的分工¶

知识回答"怎么理解"，工具回答"怎么取证"和"怎么执行"——这两类能力要一起做。只有知识没有工具，Agent 会停在建议层；只有工具没有知识，Agent 会拿到一堆数据却不知道怎么判断。

工具设计 3 个验收项¶

关键洞见：工具失败也要被当作一等信息记录——权限不足 / 超时 / 参数错误 / 数据源不可用，都不能被 Agent 粗暴吞掉。它们不一定是业务根因，却会影响这次任务的可信度。

评测：增量评测 + baseline 保留¶

核心原则¶

复用通用 Agent 的路线，评测必须看增量——增强版跑得不错，不代表知识库 / 工具 / 流程都有效；也可能裸基座本来就能做到。保留 baseline，才知道投入有没有回报。

评测集字段：不要只放输入和最终答案¶

作者洞见：Agent 是过程型系统，很多失败发生在中间——所以 expected_behavior 字段比"最终答案"重要得多。

上线门禁 6 项¶

推广节奏：按月推进，不按平台想象推进¶

关键洞见：如果一个场景连 20 条高质量 case 都凑不出来，先别急着做 Agent——没有 case，就没有 baseline；没有 baseline，后面所有优化都会靠体感。

容易踩的坑（7 个反模式）¶

收尾检查清单（9 项）¶

• 已选择通用 Agent 基座，并记录裸 baseline
• 已明确哪些能力由基座负责，哪些能力由团队增强层负责
• 任务边界 / 成功标准 / 停止条件 / 人工确认点已经写清楚
• 业务知识库 / 仓库规则 / 历史案例有维护机制
• 关键工具有清晰 schema / 错误码 / 权限边界 / trace
• 高风险动作已经接入 dry-run / 人工确认 / 回滚机制
• 评测集能比较裸基座 / 知识增强 / 工具增强 / 流程增强的效果
• 上线前能跑回归评测，并能看出每次改动的收益和损失
• 线上有任务级 trace / 工具调用日志 / 成本指标 / 失败归因

如果这些都还没有，先别急着谈平台化——把第一个真实场景跑通，把失败样本沉淀下来，把评测闭环做实。业务 Agent 的工程价值，往往就是从这些看起来不酷、但能长期工作的东西里长出来的。

与现有 Wiki 的关系¶

与 Agent Harness 工程的呼应¶

Agent Harness 架构设计 + Agent Harness Engineering Survey ETCLOVG 提供了 Harness 的 学术框架（Execution / Tooling / Context / Lifecycle / Observability / Verification / Governance）——本文提供了 业务团队的 MVP 落地路径，两者互补。Harness 框架是"通用 Agent 的 execution layer"；业务增强层是"团队给通用 Agent 补的 domain layer"。

与其他企业级 Agent 实践的呼应¶

• AgentScope Builder 企业自进化 = 阿里云 Harness 平台化（重平台路径）
• 阿里云 EventHouse 上下文构建 = 知识与上下文层的 DIKW 框架
• 本文 = 业务团队"复用基座 + 补增强层"的轻量路径（平台 vs 增强层 是两种不同的工程取舍）

与评估 / 知识管理¶

• AgentEval YAML 评测框架 = 技术评测框架（多 Agent 适配器 / pass@k + pass^k）
• 本文的评测集 = 业务评测集（带 required_evidence / forbidden_behavior / label 字段）——比纯技术评测更面向业务闭环

与失败模式¶

• Agent Reliability: Context Drift & Tool Calling Hallucination 提供了技术层的失败分析
• 本文的 7 个反模式 = 业务层的失败模式（无 baseline / 长 prompt 知识 / 过早多 Agent 化等）

与"Agent = Model + Harness"公式¶

Agent Harness 12 组件 7 决策 提出 Agent = Model + Harness——本文是这公式在企业落地时的工程展开：通用 Agent（Model + 基础 Harness）+ 业务增强层（业务能力）。

深度分析¶

1. "增强层"范式的本质：是工程分工而非模型创新¶

本文最核心的洞察并非具体技术方案，而是一种工程分工哲学——将"通用智能"与"业务约束"解耦，让通用 Agent 承担推理与执行，业务层承担边界与证据。这种分工的深层逻辑是：通用模型（Codex/Claude Code）的进化速度远快于任何垂直团队自研 Agent 的速度，业务团队选择复用基座而非自研，本质上是搭上了通用模型进化的顺风车。

2. 评测增量思想的方法论价值：对抗组织惯性¶

文章坚持"保留 baseline 才知投入回报"，这在企业落地中常常被忽视。多数团队在引入 AI Agent 后，会将主观体验当作客观依据——"感觉好用了"就认为成功。但没有 baseline 对比，任何增强投入都是黑盒。本文将"增量评测"从技术要求上升为方法论，对于防止团队在自我感动中持续投入资源具有重要的刹车作用。

3. 6 层架构的深层逻辑：信息流动的单向性¶

业务增强层架构的核心约束是信息单向流动——增强层向通用 Agent 提供上下文和工具，但不接管执行。这意味着通用 Agent 始终是决策中心，增强层是辅助支撑。这一约束的价值在于：即使增强层出错，执行层面的问题根源也容易被追溯；若让增强层接管执行循环，则工具失效和流程失控的风险会相互叠加。

4. 知识库建设的问题驱动原则：对抗"文档囤积症"¶

文章提出"先看 Agent 经常错在哪里，再反推要沉淀什么知识"，这是对传统知识库建设范式的根本性颠覆。多数企业在推进 AI 时，第一反应是"先把知识库建好"——将所有文档上传，期待 AI 自己学会。但文档的堆积不等于知识的可用。本文的核心贡献在于：将知识库建设从"仓库思维"转变为"诊断思维"，用 Agent 的失败案例反向驱动知识沉淀，这既避免了无效的知识囤积，也让知识库具备了可量化的 ROI。

5. 工具失败作为一等信息：对可观测性设计的深层启示¶

文章强调"工具失败也要被当作一等信息记录"，这对于传统可观测性设计提出了挑战。传统监控系统倾向于将错误当作需要消除的异常，但工具调用失败（如权限不足、超时、数据源不可用）对于判断 Agent 任务可信度至关重要。将失败记录从"噪音"重新定义为"信号"，是业务 Agent 可观测性设计的核心转变。

6. 时间节奏的工程哲学：MVP 而非平台¶

文章坚持"按月推进，不按平台想象推进"，这直接回应了企业 AI 项目中最大的浪费模式——在尚未验证单一场景价值时就投入平台化建设。这种节奏控制的深层逻辑是：业务 Agent 的价值来自场景闭环的积累，而非架构的统一性。平台化是价值验证后的自然延伸，而非前提假设。

实践启示¶

对业务团队¶

• 不要重造基座：把 Codex / Claude Code 当现成基座，精力集中在补 6 层增强
• 裸跑 baseline 优先：没有 baseline 就没有 ROI 量化
• 20 条 case 起步：凑不出 20 条高质量 case = 场景不成熟 = 暂缓
• 3-5 个工具起步：不要一次性接入所有内部系统
• 写操作永远要确认：写 / 删 / 通知 / 权限变更 100% 走 Gate
• 评测集比答案重要：记录 expected_behavior + required_evidence + forbidden_behavior，比记录最终答案有效 10 倍

对 AI Agent 平台建设¶

• 平台 vs 增强层是两种路径：AgentScope / EventHouse 走平台化，业务增强层走轻量复用——根据团队规模 / 资源 / 时间窗口选择
• 6 维能力分工是普适框架：任何业务 Agent 落地都可以套这 6 维检查

对 Agent 厂商¶

• 通用 Agent 的护城河在工具可接入性 + 评测工具链 + 安全治理——业务团队愿意复用基座是因为基座这三层做得好
• 业务增强层 = Agent 厂商的 toB 机会：帮业务团队把 6 层增强做实，而不是卖一个"通用 Agent + 平台"

相关实体¶

• 循环工程 (loop engineering) — 清华 2026 框架
• MOC → 原文存档