--- title: "业务 Agent 增强层架构：复用通用 Agent 基座，把业务能力做成可验证增强层" created: "2026-06-06" updated: "2026-06-06" type: raw source_url: "https://mp.weixin.qq.com/s/qysRL9BeSLt_Zpmu889xeA" source_name: "AI 小老六 WeChat MP" author: "AI 小老六" ingested: "2026-06-06" sha256: "a4f0bcc70eb22b638bb3334a51485e4117bcf637018af43a4ad4f27afa15f3ba" char_count: 7421 tags: [business-agent, augmentation-layer, general-agent-base, codex, claude-code, mvp, evaluation, observability, oncall, knowledge-base, enterprise-agent, agent-harness] sources: [] review_value: 7 review_confidence: 8 review_recommendation: strong review_stars: 4 --- 复用通用 Agent 基座，把业务知识、工具、流程和评测做成可验证增强层。 导语 很多团队一说要做业务 Agent，第一反应是搭一个自己的 Agent Framework：规划器、执行循环、工具调度、记忆、权限、人机交互，最好再做成平台。这个方向听起来完整，真正落地时却很容易把团队拖进基础设施泥潭。 我更倾向于反过来做：先把 Codex、Claude Code 这类 通用 Agent 基座 当成现成基座，让它们承担推理、代码理解、工具调用和多轮执行。业务团队的精力不要花在重写这些能力上，而是补它们缺的那部分： 业务知识、内部工具、流程规则、权限边界、评测集和线上观测 。 这样做不是偷懒。业务 Agent 的难点通常不在“模型会不会思考”，而在它能不能拿到正确上下文、调用正确系统、按团队规则停下来，并且在失败后留下可复盘的证据。把这些工程层做好，比从零造一个通用 Agent 更接近真实收益。 先跑裸基座：别急着写框架 建设前最该做的事，是拿真实任务让通用 Agent 裸跑一遍。这里的“裸跑”不是 demo，而是 10 到 30 个真实 case ：工单、告警、代码修改、发布检查、配置排查，都可以。团队先看清楚它原生能做到哪里，再决定补什么。 判断问题 更可靠的动作 不建议的动作 要不要自研 Agent？ 默认复用成熟通用 Agent，先建立 baseline 直接重写规划器、执行器和对话框架 团队该投哪里？ 投业务知识、工具封装、流程规则、权限、评测 把业务规则塞进超长 prompt 怎么判断有效？ 对比裸基座和增强版本在真实任务上的完成率 只看一次演示是否顺滑 什么算好 Agent？ 稳定、可控、可评测、可维护 看起来会聊天，但证据链不可追 如果 裸基座已经能解决 60% 的任务 ，团队应该围绕那 40% 的短板做增强。如果裸基座在关键任务上完全失效，也要先定位原因：是缺业务背景、缺工具、缺流程约束，还是安全边界根本不允许通用 Agent 接入。原因不同，方案差很多。 下面这条决策链可以作为立项前的第一道门。 图：从裸跑 baseline 到专项增强的立项判断链路 只有少数场景值得自研专项 Agent：强私有化环境、极端时延或成本约束、通用 Agent 无法接入的封闭运行时、必须深度嵌进业务系统的强流程任务，或者合规上不允许把任务交给现有基座。除此之外，先复用通常更快。 能力边界：通用基座做“智能”，团队做“落地” 业务 Agent 失败，很多时候不是模型笨，而是边界混乱。 通用 Agent 已经会读代码、拆任务、调用工具、根据观察调整路线 。团队要补的是它不可能天然知道的东西。 能力域 通用 Agent 已经擅长的部分 团队必须补上的部分 任务理解 把自然语言目标拆成计划，边执行边修正 任务模板、验收标准、停止条件、业务术语 代码与文件 读代码、改文件、运行测试、总结 diff 仓库规则、模块边界、测试命令、发布约束 工具调用 选择工具、填参数、解析结果、继续下一步 稳定 schema、错误码、权限、dry-run、回滚 上下文处理 在任务中组织信息，压缩执行状态 知识库、历史案例、检索策略、记忆写入规则 人机协作 不确定时询问用户，输出执行过程 哪些动作必须确认、交付格式、责任边界 质量保障 完成单次任务 评测集、回归体系、线上指标、失败归因 这张表背后的取舍很简单：不要让团队去维护一个“比 Codex 更懂代码、比 Claude Code 更会工具调用”的大系统。更有价值的是让通用 Agent 更懂当前团队，能看到内部系统，并且知道什么时候必须停下来。 图：通用 Agent 基座之外，业务团队真正需要补齐的是知识、工具、流程、安全与评测。 适合做 Agent 的任务长什么样 并不是所有需求都该做成 Agent。好的候选场景通常有几个特征： 高频、重复、边界清楚、工具可接入、结果可验证、风险可控制 。反过来，如果用户只说“帮我自动处理一切”，输入输出都说不清，Agent 项目大概率会变成无底洞。 评估项 适合推进 暂缓推进 任务边界 输入、输出、停止条件清楚 目标无法验收，成功标准靠感觉 工具可得性 关键数据和动作有 API、CLI、MCP 或内部平台 只能靠人肉经验，无法结构化调用 结果验证 可用测试、日志、规则、人工标注或业务指标判断 对错没有可沉淀标准 风险控制 高风险动作可 dry-run、审批、回滚或人工确认 一次误操作不可恢复 收益空间 高频耗时，增强后能节省明显人力 低频一次性任务，维护成本高于收益 我会优先选 Oncall 排障、发布前检查、代码迁移、灰度回归、数据修复辅助这类场景。它们有明确入口，也有证据来源。Agent 不需要凭空发挥，只要把散落在日志、代码、配置、工单和历史案例里的信息串起来。 增强层架构：把业务能力接到通用基座旁边 推荐架构不是“再造一个 Agent”，而是在通用 Agent 外面包一层业务增强。入口、知识、工具、流程、安全、评测各司其职。通用基座仍然处在执行中心， 增强层负责把真实业务世界接进来 。 图：业务入口、增强层与通用 Agent 基座的协作关系 各层的建设重点可以收敛成一张表。 层次 职责 建设重点 业务入口层 承接用户任务和人机交互 飞书机器人、Web、CLI、工单入口、命令模板 知识与上下文层 给基座补业务语境 SOP、历史案例、仓库规则、服务画像、记忆策略 工具能力层 让 Agent 查得到、做得动 MCP Server、内部 CLI、OpenAPI、日志、CI、发布、配置查询 流程编排层 约束任务推进方式 任务模板、审批点、人工确认、失败兜底、交付格式 安全治理层 守住权限和变更边界 读写分离、最小权限、dry-run、敏感动作确认、回滚 评测观测层 判断增强是否真的有用 baseline 对比、回归集、trace、指标、失败归因、成本统计 第一版不必做完整平台。选一个真实场景，接入最小知识集和最小工具集，跑通闭环，再决定要不要服务化。 MVP 闭环：少做平台，多做可验证协议 MVP 至少要回答六件事 。 问题 MVP 中的最小做法 选哪个基座 明确使用 Codex、Claude Code 或同类 Agent，并记录裸跑结果 任务怎么进来 写清输入、目标、约束、输出结构、停止条件 知识怎么给 先接 SOP、关键文档、历史案例、仓库规则 工具怎么接 只接 3 到 5 个高价值工具，优先读操作和低风险动作 风险怎么控 写操作、权限变更、外部通知、删除必须人工确认 效果怎么评 每次真实任务尽量沉淀成 case，进入回归集 配置文件不需要复杂。它要让 Agent 知道边界、证据来源和交付格式，而不是把业务流程写成一堆死板分支。 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 执行任务时必须遵守的协议。 图：知识、工具和评测应该形成持续反馈，而不是一次性资料堆砌。 1. Read: 先读任务输入、业务知识和必要上下文 2. Plan: 给出短计划，说明需要哪些证据和工具 3. Act: 调内部工具取证，参数来源必须能在上下文里追到 4. Observe: 读工具返回，保留支持假设和推翻假设的证据 5. Gate: 写操作、权限、通知、删除必须请求人工确认 6. Finish: 交付结论、证据、置信度、仍缺的信息和下一步建议 知识库不是资料仓库 ，是给 Agent 用的判断材料 知识库最容易做偏：把所有文档搬进去，最后检索命中一堆长文，Agent 看似“有上下文”，实际仍然找不到能支撑判断的证据。 更好的切入点是 问题清单 。先看 Agent 经常错在哪里，再反推要沉淀什么知识。 Agent 的典型缺口 需要沉淀的知识 示例 不懂业务背景 业务术语、服务职责、上下游依赖、核心链路 某服务负责什么，依赖哪些 RPC、MQ、DB 不会排查 SOP、Runbook、排障步骤、常用查询入口 错误率升高先看哪些指标、日志、发布变更 不懂代码边界 模块分层、owner、测试命令、发布约束 某目录归谁维护，改动后跑哪些测试 不会判断风险 权限规则、敏感操作清单、人工确认点 哪些操作只能 dry-run，哪些必须审批 缺少历史经验 历史事故、典型 case、失败复盘、常见误判 相似告警过去的根因、修复方式和误判点 知识处理流程可以设计成一条运营流水线。 图：面向任务判断的知识沉淀与失败回流流程 知识块的元数据不要省。没有 owner、更新时间、适用范围和证据来源的知识，迟早会变成噪音。 字段 作用 示例 title 直接说明这个块能解决什么问题 IM 消息发送失败的日志排查步骤 scenario 限定适用场景 oncall_diagnosis、code_review、release_check service_or_module 绑定服务、模块或仓库 message-service、openapi、client-ios content 写步骤、判断标准、注意事项和链接 先查错误码，再查 logid，再比对发布变更 evidence_source 标注来源 Runbook、事故复盘、代码路径、接口文档 owner 维护责任人 服务 owner、平台 owner、oncall owner freshness 更新时间和过期策略 90 天未确认需复审 confidence 可信等级 official、verified_case、draft、deprecated 知识库接入也不只有 RAG。稳定且必须遵守的规则适合写进 Workspace Rules；实时数据应该走工具查询；历史工单和事故复盘更适合做案例库；用户偏好和服务习惯可以进入长期记忆，但写入门槛必须高。 工具设计：让 Agent 少猜参数，少猜结果 知识回答“怎么理解”，工具回答“怎么取证”和“怎么执行” 。这两类能力要一起做。只有知识没有工具，Agent 会停在建议层；只有工具没有知识，Agent 会拿到一堆数据却不知道怎么判断。 建设项 建议做法 验收标准 工具 schema 参数结构化，返回 success、data、evidence、error_code、next_hint Agent 能稳定选工具、填参数、判断成败 权限控制 读写分离，高风险动作单独工具并要求确认 敏感动作 100% 进入确认或审批 可观测日志 记录 tool_name、args、result、latency、trace_id 每次任务都能复盘模型调用、工具调用和关键证据 工具失败也要被当作一等信息记录。权限不足、超时、参数错误、数据源不可用，都不能被 Agent 粗暴吞掉。它们不一定是业务根因，却会影响这次任务的可信度。 评测：只问“能不能用”是不够的 复用通用 Agent 的路线， 评测必须看增量 。增强版跑得不错，不代表知识库、工具和流程都有效；也可能裸基座本来就能做到。 保留 baseline ，才知道投入有没有回报。 图：从裸基座到治理闭环的增量评测路径 评测集里不要只放输入和最终答案。Agent 是过程型系统，很多失败发生在中间。 字段 说明 case_id 稳定唯一标识，便于长期追踪 input 用户真实输入或脱敏后的任务上下文 expected_behavior 期望 Agent 做什么，而不只是最终答案 required_evidence 必须引用的日志、文档、代码、指标或工具结果 forbidden_behavior 不能无证据下结论、绕过审批、误删数据 label 人工标注结果、失败类型、优先级和备注 上线门禁可以先设得朴素一些，但必须可执行。 门禁项 建议标准 核心评测集通过率 关键路径不低于 90%，P0/P1 case 必须全部通过 相对 baseline 提升 完成率、证据质量或人效有明确提升 高风险动作确认 写操作、删除、外部通知、权限变更确认覆盖率 100% 证据质量 结论必须可追溯，无证据结论率控制在 5% 以下 回归稳定性 知识、工具、流程变更后必须跑回归，失败要归因 观测完整性 每次任务能追到模型调用、工具调用、耗时、错误和最终输出 从试点到规模化：按月推进，不按平台想象推进 比较稳的节奏是一个月做出可验证闭环，第二个月小流量试用，第三个月再谈跨场景复用。 阶段 目标 交付物 第 1 周 选定场景，跑通裸基座 baseline 基座选型、任务协议、20 到 50 条初始 case、baseline 结果 第 2 周 补最小知识库和关键工具 SOP、历史案例、3 到 5 个工具、结构化输出模板 第 3 周 补流程和可控性 人工确认、风险动作列表、trace、错误处理、交付规范 第 4 周 建立 baseline 对比评测 评测集、对比报告、失败归因、迭代计划 第 2 个月 小流量试用 灰度策略、反馈入口、成本统计、回归流水线 第 3 个月 扩展到更多场景 知识库运营机制、工具目录、权限治理、复用模板 这里有个朴素判断：如果一个场景连 20 条高质量 case 都凑不出来，先别急着做 Agent。没有 case，就没有 baseline；没有 baseline，后面所有优化都会靠体感。 几个容易踩的坑 业务 Agent 的坑通常不是模型能力不足，而是工程判断失准。 • 重复造通用 Agent：团队把时间花在重做推理、对话、代码操作和工具调用框架上，迭代速度反而慢。 • 没有 baseline：只看增强后的效果，不知道比裸基座好在哪里。 • 把知识写进长 prompt：短期能跑，长期难更新、难评测，也很难定位回归。 • 工具设计太粗：Agent 要自己猜参数、猜结果、猜下一步，稳定性会很快下降。 • 忽视流程约束：通用 Agent 会做任务，但不天然知道组织里的审批、交付和责任边界。 • 没有评测集：优化靠体感，改一次坏一次。 • 过早多 Agent 化：多 Agent 会引入协作、成本和排障复杂度。先把单闭环做好。 结语：业务 Agent 的价值在增强层 业务 Agent 的关键不在“团队有没有造出完整 Agent”，而在是否用成熟通用 Agent 快速解决真实问题，并通过知识、工具、流程和评测把效果稳定下来。 落地时可以用这份检查清单收尾。 • 已选择通用 Agent 基座，并记录裸 baseline。 • 已明确哪些能力由基座负责，哪些能力由团队增强层负责。 • 任务边界、成功标准、停止条件和人工确认点已经写清楚。 • 业务知识库、仓库规则和历史案例有维护机制。 • 关键工具有清晰 schema、错误码、权限边界和 trace。 • 高风险动作已经接入 dry-run、人工确认或回滚机制。 • 评测集能比较裸基座、知识增强、工具增强、流程增强的效果。 • 上线前能跑回归评测，并能看出每次改动的收益和损失。 • 线上有任务级 trace、工具调用日志、成本指标和失败归因。 如果这些都还没有，先别急着谈平台化。把 第一个真实场景跑通 ，把失败样本沉淀下来，把评测闭环做实。 业务 Agent 的工程价值 ，往往就是从这些看起来不酷、但能长期工作的东西里长出来的。 推荐阅读 Dynamic Workflows 深度解析：Claude Code 为什么把多 Agent 编排写进可执行代码 Codex Context Compaction 真相：Agent 为什么压缩后还能接着干活？ Agent Harness 架构真相：Prompt Cache 如何决定 Skill、MCP 与 SubAgent 设计 平台智能化到了分水岭：为什么配置代码化才是 AI Coding 的下一代接口 Hermes Agent /goal 长任务运行时架构拆解：状态持久化、Judge 闭环与自主续航 --- ## 元信息 - **来源 URL**: https://mp.weixin.qq.com/s/qysRL9BeSLt_Zpmu889xeA - **抓取时间**: 2026-06-06 - **抓取方式**: urllib + js_content 提取 - **作者**: AI 小老六 (微信公众号)