通用 Agent 已经能写代码、整理文档、分析数据，企业还有必要自己折腾吗？作者把它拆成两件事：搭 Agent 运行底座，和在底座上开发业务 Agent；真正省不掉的，是内部工具、业务规则、流程梳理和效果验证。

最近一段时间，大家应该都感觉到了，Agent的发展速度非常快。

从OpenClaw、Hermes、到 Codex、WorkBuddy、QoderWork、豆包工作，各种Agent产品接连进入大家的视野，大厂也都下场角逐通用Agent市场，Agent能做到事情也是越来越多。

写代码、整理文档、分析数据，越来越多的工作可以直接交给现成通用Agent来完成。对于个人和小团队来说，这些工具已经带来了非常明显的提效。

但我最近接触的一些企业，在准备落地Agent的时候，还是希望自己开发做一个。

于是就会有同学问：通用Agent已经这么强了，企业还有必要自己折腾吗？

现在不少产品支持MCP、Skills等扩展能力，有些还提供Agent的企业版。我们只需要把内部工具接入进去，把业务流程写成Skill，是不是就够了？记忆管理、会话压缩、工具治理这些基础能力，自己做又未必比现成产品更好。

这个问题确实值得我们仔细思考。在此之前我们需要来看看企业开发自己的业务Agent需要做些什么，我觉得可以分成2件事情

一件是自己搭建Agent的运行底座，另一件是在已有底座上开发自己的业务Agent。

所谓的Agent的运行底座 也就是Agent harness 那一套东西，涉及记忆管理、会话压缩、工具治理这些基础能力，也是通用Agent比较完善的能力。自己的业务Agent，这一块主要涉及内部工具开发、业务规则梳理、流程梳理和效果验证，这一块内容 不管是自研Agent还是使用通用Agent，工作多不能省去。

比如我们想做一个售后Agent，它运行在什么产品上，我们可以选择通用Agent，也可以选择自研，它怎么查订单、怎样判断退款条件、处理错了怎么发现和修正，都需要自己处理。

Agent替我们做好了什么

我们先来看一下，如果我们自己开发一个Agent，要让它运行起来，要做些什么，我们可以先用一个简化的公式来理解：Agent = Model + Harness。

模型负责根据用户请求和上下文，生成回答或提出工具调用请求。但模型提出调用请求以后，还需要一套程序执行工具，把结果交回模型，让它继续判断下一步该做什么。

这个过程会反复进行，直到任务完成，或者满足停止条件。

这套支撑Agent运行的基础设施，我们把它称为Harness。除了模型与工具之间的执行循环，它还可以包含上下文管理、状态保存、工具治理和异常处理等能力。

通用Agent产品已经替我们完成了其中不少工作，如果使用通用Agent，我们可以直接提交任务，不必再管底层的运行机制。只需要梳理业务规则，看能不能再上面做业务实现即可。

一般的通用Agent产品都支持MCP和Skills，我们就可以把业务系统相关的工具通过MCP接入到Agent中，再用Skill说明业务流程和工具的使用方式，就可以把我们的业务工作流搬到Agent上面执行。

比如，先把订单查询和退款申请接口接入到MCP，再写一个处理退款售后的Skill。用户提出退款要求后，Agent就可以查询订单、参考售后规则，尝试完成申请。

所以，通用Agent加MCP和Skills，确实是一条值得先尝试的路径。

企业自己需要开发什么

公司已经有业务接口，是不是套一层MCP就可以了？

正常来说，是不推荐这样使用的，公司已有的业务API接口，是为之前系统前端界面服务的，不是给Agent定制的工具，它们的处理方式是不一样的。在早期的测试验证阶段，可以先这样测试，验证方案的可行性。觉得可行了，在改造成Agent工具。

例如客服处理一笔售后，可能要分别查看订单详情、支付记录、优惠信息和历史退款记录。员工知道这些信息在哪里，它可以去查看验证数据。如果直接暴露所有底层接口，Agent就得自己判断查哪些数据、按什么顺序查，以及这些数据之间是什么关系。

我们可以把这些查询封装成一个面向售后的工具，一次就返回处理退款需要的信息。这样就减少了Agent反复选择接口、拼接数据的工作。

封装时还有不少细节。比如金额单位是分，就要在工具描述里写清楚。查询失败时，也不能随便返回一个空结果，否则Agent可能以为这笔订单不存在。

如果工具是写操作的话，还要处理重复调用，比如创建退款申请，业务系统已经处理成功，但响应超时了，Agent可能会根据返回的错误再重试一次。这时系统要能查询上一次的执行结果，并通过幂等机制避免重复创建申请。

权限也需要在工具和业务系统里做实际检查。售后员工只能处理自己负责的订单，Agent帮他操作时，就应该受到同样的限制。发起任务的用户身份需要传递到执行环节，不能因为调用方变成了Agent，就跳过原有的授权规则。

所以，工具开发不只是让接口能被调用，我们还要让它提供足够的业务信息，让成功、失败和执行状态可以被明确区分，并在实际操作时能够遵守业务约束。

把员工默认知道的经验写进Skills

我们把工具开发好以后，还需要告诉Agent，这家公司的售后流程是怎么样，具体应该怎么去处理。

比如收到退款要求后，先确认是哪笔订单，再查询相关记录。如果用户没有提供订单号，也没有其他足以确定订单的信息，就应该先询问客户。后面的退款条件、审批流程和转人工要求，也要按公司的实际规则写清楚。

难点往往在于，现有SOP省略了员工默认知道的内容，也就是开发业务Agent，我们需要重新梳理业务。

比如文档里写着 特殊订单联系主管处理 。员工可能知道什么叫特殊订单，但我们不能指望Agent也知道。需要找业务同学确认具体条件，并说明转给主管时要带上哪些信息，方便主管做出判断，不能只留下一句 人工处理 。

有时候梳理这些业务规则，还会发现文档可能已经过期，或者两个部门对同一条规则的理解不一样。这时需要先确认业务规则，业务不清，不管怎么修改提示词也解决不了这个分歧。

当然，我们不用把所有内容都塞进Skill。经常变化的商品政策，可以通过检索工具获取，有明确公式可以计算的退款金额，可以交给计算工具处理，再给Skill说明什么时候调用。

做到这里，我们就能看到，开发工具和Skills，很大一部分工作是在理解业务、整理规则，再把它们变成可以执行和验证的能力。

还需要哪些能力

工具写好了，流程也梳理清楚了，我们就可以接入Agent，可以尝试处理售后问题。接下来还要回答几个关键问题：任务中间断了该怎么处理，业务出错了怎么排查，怎么检查业务是不是变好了。

这些问题分别对应Agent运行时、可观测和评测能力。

系统需要这些能力，并不意味着要把它们需要全部自行开发。 通用产品、开源框架和公司已有系统能提供的部分，可以直接复用，缺少的部分，再根据实际需求补齐。

Agent运行时

我们先看下Agent运行时，这个也就是我们的Harness，Harness也可以复用已有产品或框架。如果业务场景简单，自己写一个模型与工具的执行循环，也不会非常复杂。

harness这块内容我们就不重复讲了，通用Agent主要就是提供Agent的harness实现。

Agent的可观察性

Agent可观察性 这个是给产品和研发看的，业务不一定需要看这个。

我们把Agent运行起来以后，用户反馈说处理太慢了，业务只会给产研反馈，系统太慢了，需要优化，如果有这个可观察性系统，我们怎么知道哪里变慢了，那个任务的的token消耗很高，如果没有可观察就没办法排查。这个是业务上生产一个必不可少的条件。

这个观察性，需要把模型调用和工具执行记录关联到每一次任务上，公司如果已经有日志和链路追踪系统，可以直接接入进去。任务量增加以后，再通过看板观察失败、耗时和费用变化。

比如所有工具都返回成功，退款申请也创建了，但金额不对。如果我们只关注接口有没有报错，就会漏掉这个问题。Agent总会尽可能的帮助我们完成任务，不管中间有没有报错，还是最终的结果对不对，它都会生成一个看是合理的成功的回复，业务上我们一定需要自己做好检查。

排查问题时，我们需要找到这次任务的执行轨迹，查看工具返回了哪些订单数据，Agent提交了什么参数，以及最终生成了什么业务单据。

如果工具返回的数据缺少优惠卷的信息，就要检查查询工具是否有问题，如果数据完整，再检查当时使用的规则和计算过程，看看模型的推理是否正常。任务所用的模型、工具、Skill及相关配置版本也要能追溯，不能拿今天的配置去猜昨天发生了什么。

Agent评测

有了可观性的记录，我们可以排查已经发生的问题。但是每次上线前或者每次修改bug以后，怎么判断任务业务还能正常运行，这个还是需要测试，也就是我们常说的Agent评测。

我们还是以售后为例。Agent跑完之后，给了一个回复 退款申请已提交，我们不能只判断Agent返回了这句话就说它成功了吧，而是要确认售后系统里确实创建了退款申请，并且金额正确，需要审批的订单也走了审批流程。

这些东西其实也就是我们常说的测试用例，测试需要覆盖所有业务场景，并针对不同的场景设计合理的用例。

准备案例时，可以先覆盖普通退款，再加入优惠券订单、部分退款等情况。在正常流程之外，还需要处理一些异常情况，比如接口超时、用户没有权限，转人工测试。

这样，当我们修改Skill、调整工具或更换模型配置时，就能重新运行已经建设好的案例。比如 修好了优惠券订单的问题，还要检查普通订单有没有受到影响。关键案例可以多跑几次，并分别看不同业务场景的表现。

测试案例多了以后，再用评测平台统一管理、批量运行和版本比较。平台可以选择现成工具，但拿什么案例测、怎样算通过，仍然需要企业自己准备。

如何通过反馈持续改进

前面讲了工具、Skills，以及运行、观测和评测能力。它们最终要一起服务于实际业务中的改进。

比如业务同学发现一笔促销订单的退款金额不对，手动改了回来。

如果改完就结束了，开发团队不知道这件事，下次Agent处理同类订单，仍然可能出错。我们需要让业务同学方便地反馈问题，并把修改前后的结果、修改原因关联到原始任务。

借助执行记录，假设我们发现查询工具漏掉了促销优惠的分摊信息，导致后续计算使用了不完整的数据。问题定位之后，我们还需要修改工具执行逻辑，补齐数据，并检查计算与校验逻辑。

然后，把这笔订单犯的错误整理成评测案例，并且确认修复bug有效，再运行其他退款案例，检查有没有引入新的问题。验证通过后发布新版本，继续观察同类订单是否还需要人工纠正。

这样，前面几部分就连起来了：业务反馈提供问题，观测帮助定位原因，工具和规则承载修复，评测验证改动，上线后的结果再检验效果。

处理得好的案例也可以积累。比如业务同学有一套经常采用的方法，就可以一起确认适用范围，再补进Skill。

这种持续的改进 ，补一个工具字段，明确一条业务规则，增加一个评测案例，都可能帮助我们减少同类问题。

随着积累，企业会逐渐拥有更完整的业务工具、更明确的流程说明，以及覆盖更多真实情况的评测案例。这些内容能为后续迭代提供依据。

这个过程同样需要有人持续跟进，只是把日志存下来，没有人看、没有人处理，Agent不会因为用的次数多了就自动变好。

什么时候需要自建Agent底座

现在我们再回到开头的问题：通用Agent这么强，企业还需要自己开发什么？

如果我们的目标是让Agent进入实际业务，那么内部工具、业务规则、效果验证和反馈改进，往往仍然需要企业深度参与建设。至于运行底座要不要自己搭，则要看已有产品能否承接这些需求。

我的想法是，想要使用Agent来提效，先选一个范围明确的业务，在现成产品上试一试，看看效果。

准备好业务接入必要的工具和Skill，用准备好的案例检查结果，再验证任务能否按业务要求发起，审批等环节能否正确暂停和恢复，出错后能否查到完整执行过程。这里就有一个很麻烦的点，就是现在的通用Agent基本都不会提供完整的执行日志，所以我们看到的就是一个巨大的黑盒。

所以如果真的想要把业务接入Agent，通用Agent并不是一个很好的选择，当然如果你的业务很简单，不需要考虑太多的观察和评测机制的建设，使用通用Agent带来的稳定运行机制也是非常不错的选择。

我们也可以考虑一些开发Agent的开源框架，比如：agentScope，deepseek harness 等，这样就少了一部分的基建工作，就可以直接在上面开发自己的业务Agent。