7.7
深览指数
产品Bestblogs·叶小钗··AI 生成
WorkBuddy/CodeX 都这么强了，企业还要花钱自研智能体吗？
文章提出企业开发Agent应拆解为「运行底座」和「业务Agent」两件事，前者通用产品已较成熟、可复用，后者无论是自研还是用现成产品都省不掉。作者以售后Agent为例，详细拆解了工具封装（单位统一、幂等、权限传递）、业务规则显式化（隐性经验转Skill）、可观测性（关联模型调用与执行日志）、以及以业务结果为准的评测体系等工程细节。核心结论是：通用Agent因缺乏完整执行日志、形同黑盒，是接入真实业务的主要障碍，建议先选范围明确的业务在现成产品上试跑，遇到根本性限制再考虑开源框架。适合正在评估或规划Agent落地的技术负责人、AI工程团队阅读。原文 ↗
核心观点
- ▍企业做Agent应拆成「运行底座」和「业务Agent」两件事，前者可复用通用产品，后者无论自研还是用现成方案都省不掉。
- ▍通用Agent（如WorkBuddy/CodeX）加MCP和Skills是值得先试跑的路径，但因缺乏完整执行日志、形同黑盒，是接入真实业务的主要障碍。
- 01公司内部API是为前端界面设计的，不是为Agent定制的工具；直接暴露给Agent会导致其自行判断数据查询顺序和范围，应封装成面向场景的一次性调用工具。
- 02工具封装需处理：金额单位在描述中写清、查询失败返回明确错误信息而非空结果、写操作带幂等键防重复、发起任务的用户身份传递到执行环节。
- 03Skill难点是把员工默认知道的隐性经验显性化，如「特殊订单联系主管」中的「特殊订单」定义；若两个部门对规则理解不一致，必须先确认业务规则。
- 04可观测性需将模型调用和工具执行关联到具体任务，并追溯模型、工具、Skill及配置版本，才能定位失败原因。
- 05评测应以业务结果为准，例如确认售后系统里确实创建了退款申请且金额正确，而非只看Agent回复「已提交」。
反方 / 局限
- — 观点：现在的通用Agent基本不提供完整执行日志，所以我们看到的就是一个巨大的黑盒。这意味着企业在评估试跑效果时，可能因缺乏可观测性而低估或高估Agent的实际性能。
- — 暗示：文章作者发明了「Harness」这一分析框架并大力推荐，但该框架在行业内的接受度与成熟度不详，企业采纳需要额外学习与改造成本。
5 分钟 · 3 卡片 · 6 资料
读原文 →