通用 Agent 这么强，企业还要自己开发业务智能体吗？
把企业自研业务 Agent 拆成「搭运行底座」和「在底座上开发业务 Agent」两件事：通用 Agent 已经替公司完成了底座（Harness）的大部分工作，真正省不掉的是内部工具、业务规则、流程梳理和效果验证。
基本信息
- 来源类型：文章（人人都是产品经理）
- 原文位置：
raw/articles/2026-09-17-171025-tg-bca050.md - 原文 URL：https://www.woshipm.com/ai/6465870.html
- 作者：叶小钗（原鹅厂、百度一线开发，B站技术专家；AI产品项目负责人）
- 发布日期：2026-09-17
- 消化日期：2026-09-16
核心观点
-
企业自研业务 Agent 分两件事：搭「运行底座」+ 在底座上开发「业务 Agent」。运行底座即 Agent harness（记忆管理、会话压缩、工具治理等基础能力），通用 Agent 已经把这部分做得很完善；真正省不掉的是业务侧工作——内部工具开发、业务规则梳理、流程梳理和效果验证，这块无论自研还是用通用 Agent 都不能省。
-
简化公式
Agent = Model + Harness：模型负责根据用户请求和上下文生成回答或提出工具调用请求；Harness 是一套执行循环基础设施，把工具结果交回模型继续判断下一步，反复直到任务完成或满足停止条件。Harness 还包含上下文管理、状态保存、工具治理和异常处理。 -
通用 Agent + MCP + Skills 是一条值得先尝试的路径：主流通用 Agent 产品都支持 MCP 和 Skills，把业务系统工具通过 MCP 接入、用 Skill 说明业务流程和工具用法，就能把业务工作流搬到 Agent 上执行（例如：把订单查询和退款接口接入 MCP，再写一个退款售后 Skill）。
-
公司已有业务 API 不宜直接套 MCP，要先封装成「面向业务场景的工具」：客服处理一笔售后要分别查订单详情、支付记录、优惠信息、历史退款记录，如果直接暴露所有底层接口，Agent 得自己判断查哪些数据、按什么顺序查、数据间什么关系。封装成一次返回处理退款所需信息的工具，减少 Agent 反复选接口、拼接数据的工作。封装细节包括：金额单位是分要在工具描述里写清楚、查询失败不能返回空结果（否则 Agent 以为订单不存在）、写操作要处理重复调用（幂等）、权限必须在工具和业务系统里做实检查。
-
开发工具和 Skills 很大一部分工作是把员工默认知道的经验显性化：现有 SOP 省略了员工默认知道的内容（比如「特殊订单联系主管处理」——员工知道什么叫特殊订单，Agent 不知道），需要找业务同学确认具体条件、明确转给主管要带哪些信息。梳理时还会发现文档过期或两个部门对同一条规则理解不一致——这时业务不清，改提示词也解决不了。
-
除了工具和 Skills，还需要三种能力：Agent 运行时、可观测性、评测。系统需要这些能力不代表要全部自研，通用产品、开源框架和公司已有系统能复用的直接复用。可观测性（给产研看）需要把模型调用和工具执行记录关联到每次任务上，接入公司已有日志/链路追踪系统；评测则是上线前或改 bug 后判断业务是否仍正常运行的测试，案例要覆盖普通退款、优惠券订单、部分退款、接口超时、无权限、转人工等场景。
-
通用 Agent 最大的短板是「黑盒」——基本不提供完整执行日志。如果要把业务真正接入 Agent，需要可观测性和评测机制，通用 Agent 未必是最好选择；业务简单、不需要太多观测/评测机制时，通用 Agent 的稳定运行机制反而是不错选择。也可以考虑开源框架（agentScope、deepseek harness）少做部分基建，直接在上面开发业务 Agent。
实操内容保留
企业做售后 Agent 的落地路径（分步操作）
- 接入工具：把订单查询、退款申请等业务接口通过 MCP 模型上下文协议 接入，写一个处理退款售后的 Skill。用户提出退款要求后，Agent 查询订单、参考售后规则，尝试完成申请。
- 封装面向场景的工具：把分散的查询（订单详情、支付记录、优惠信息、历史退款）封装成一个面向售后的工具，一次返回处理退款所需信息。工具描述里写清金额单位是分；查询失败不要返回空结果；写操作（如创建退款申请）要处理重复调用，用幂等机制避免重复创建（业务系统已处理成功但响应超时，Agent 可能根据错误重试）。
- 权限检查：售后员工只能处理自己负责的订单，Agent 帮他操作时受同样限制；发起任务的用户身份需传递到执行环节，不能因调用方变成 Agent 就跳过原有授权规则。
- 把业务规则写进 Skill：收到退款要求先确认是哪笔订单，再查相关记录；用户没提供订单号且无其他足以确定订单的信息，就先询问客户；退款条件、审批流程、转人工要求按公司实际规则写清楚。经常变化的商品政策用检索工具获取，有明确公式计算的退款金额交给计算工具处理，Give Skill 说明什么时候调用。
- 补充可观测性：把模型调用和工具执行记录关联到每次任务，接入公司已有日志/链路追踪系统；任务量增加后通过看板观察失败、耗时和费用变化。
- 建立评测案例：先覆盖普通退款，再加入优惠券订单、部分退款等；正常流程外处理异常情况（接口超时、用户无权限、转人工测试）。改 Skill/工具/模型配置时重跑案例，关键案例多跑几次看不同场景表现。案例多了用评测平台统一管理、批量运行、版本比较。
关键概念
- Agent Harness — Agent 运行底座，含上下文管理、状态保存、工具治理、异常处理
- Agent Memory — 记忆管理，底座的一部分基础能力
- 上下文工程 — 会话压缩 / 上下文管理，底座基础能力
- MCP 模型上下文协议 — 把业务系统工具接入 Agent 的标准方式
- Skill — 用来说明业务流程和工具使用方式
- Agent 工作流测试集 — Agent 评测，用真实案例验证业务是否正常运行
- DeepSeek Harness — 可选的开发 Agent 开源框架之一
- Agent Scope — 可选的开发 Agent 开源框架之一（agentScope）
- 可观测性 — 把模型调用和工具执行记录关联到每次任务上（本文核心短板）
- 幂等 — 写操作避免重复创建申请的机制（本文点名，暂无独立实体页）
- 工具治理 — harness 基础能力之一（本文点名，暂无独立实体页）
与其他素材的关联
- 与 企业AI落地 主题高度同源：本文的「先梳理业务规则、再做工具、再评测验证」与主题里「先治数据和流程再上智能体」「Agent 工作流测试集 用真实案例回归」完全同构。
- 与 2026-07-17-woshipm-course-consulting-assistant-3-iterations 的服务闭环呼应：都强调「模型答得对 ≠ 业务解决了」，需要任务路由、可观测和评测。
- 与 2026-07-07-woshipm-agent-safety-guardrails 的 Agent安全护栏 呼应：都指出写操作要处理幂等/重复调用、权限要在真实系统检查，不能因调用方变成 Agent 就跳过规则。
- 与 2026-07-05-juejin-context-engineering-harness 的 Harness闭环工程 呼应：Harness 是本文「运行底座」的核心。
- 与 2026-05-26-智能客服MVP三件事 呼应：都用「大模型只做翻译层 + 确定性流程 + 业务 API 闭环」的轻量范式，本文进一步强调工具要面向场景封装。
- 与 2026-08-11-smart-cs-evaluation-framework 呼应：评测有三层（模型质量/任务完成/业务指标），本文的评测案例正对应任务完成层和业务指标层。
原文精彩摘录
所谓的 Agent的运行底座 也就是Agent harness 那一套东西，涉及记忆管理、会话压缩、工具治理这些基础能力，也是通用Agent比较完善的能力。自己的业务Agent，这一块主要涉及内部工具开发、业务规则梳理、流程梳理和效果验证，这一块内容 不管是自研Agent还是使用通用Agent，工作多不能省去。
正常来说，是不推荐这样使用的，公司已有的业务API接口，是为之前系统前端界面服务的，不是给Agent定制的工具，它们的处理方式是不一样的……我们可以把这些查询封装成一个面向售后的工具，一次就返回处理退款需要的信息。这样就减少了Agent反复选择接口、拼接数据的工作。
如果工具是写操作的话，还要处理重复调用，比如创建退款申请，业务系统已经处理成功，但响应超时了，Agent可能会根据返回的错误再重试一次。这时系统要能查询上一次的执行结果，并通过幂等机制避免重复创建申请。
这个观察性，需要把模型调用和工具执行记录关联到每一次任务上……排查问题时，我们需要找到这次任务的执行轨迹，查看工具返回了哪些订单数据，Agent提交了什么参数，以及最终生成了什么业务单据。
这里就有一个很麻烦的点，就是现在的通用Agent基本都不会提供完整的执行日志，所以我们看到的就是一个巨大的黑盒。所以如果真的想要把业务接入Agent，通用Agent并不是一个很好的选择。