背景

起因是：看群里一直说现在面试都是招 Agent 开发，我想了一下，对于 Agent 的了解并没有太多，只是听到别人天天提起，但具体说什么是 Agent，怎么封装 Agent，都不熟悉，所以就想着实际体验一下

调研

Agent 开发是什么

具体步骤，先了解一下 Agent 开发是做什么的，回头能说出个一二三。

Agent 开发的核心，是让模型从“会回答”变成“会感知、会规划、会调用工具、会执行任务并能自我修正”的系统。

Agent 开发不是只写一个聊天机器人，而是围绕目标、环境、工具、记忆、规划、执行和评估，搭建一个能持续完成任务的智能应用。

Agent 开发要做的事情，就是把大模型放进一个可控的执行系统里，让它在明确边界内理解目标、拆解任务、调用工具、处理反馈，并稳定完成真实任务。

Agent 开发和普通 AI 应用开发的区别

普通 AI 应用更像是“输入问题，输出答案”。Agent 应用更像是“输入目标，系统自己决定怎么完成”。
两者的差异主要在于 Agent 需要更强的行动能力。它不仅要生成内容，还要调用工具、观察结果、调整计划、维护状态，并在多步骤任务中保持一致性。因此，Agent 开发更接近“AI + 软件工程 + 自动化流程 + 安全控制”的结合。

Agent 的操控入口是什么？

Agent 的操控入口就是“任务进入 Agent 系统的门”。它可以是聊天框，也可以是按钮、API、工作流事件、浏览器侧边栏或业务系统页面；入口设计得越清晰，Agent 的执行就越稳定、越可控。

一个最小可用 Agent 通常包含什么

如果只是做一个 MVP，可以先从最小闭环开始：一个明确任务场景，一个模型，一个或几个工具，一个简单的记忆或知识库，一个执行流程，一个日志和评估机制。
例如做一个“网页资料整理 Agent”，最小版本可以是：用户输入目标，Agent 读取网页内容，抽取关键信息，整理成结构化表格，并在信息不足时询问用户。这个版本不需要一开始就支持所有网站、所有格式和所有自动化操作，先把一个核心场景做稳定更重要。

实践

巧了，我刚好有个任务场景，于是就借着这个任务场景体验一下整个流程。场景如下：

线上订阅会有丢单的情况：

  1. 每次出现问题后，用户反馈到客服，客服反馈到开发
  2. 开发通过用户反馈的OrderId，通过接口查询苹果的具体交易信息，然后获取到 transactionId
  3. 再去后台打开订单列表根据 交易ID 查询，查询到记录后，看能否找到订单；找到后查看状态，是否是购买成功；然后找到用户ID；
  4. 再打开后台的用户列表，根据 用户ID 查询，看当前用户的状态（或余额）是否正确，能否和充值订阅对应起来；
  5. 如果查到了，则看是否和用户反馈的用户id一致； - 如果用户ID一致，则检查状态是否和 交易后的数据一致 - 如果用户ID不一致，则根据上面查到的用户的 ccid，再根据 ccid 查询，看是否是存在同一个 ccid 多个用户的情况，即充值订阅是否绑定到了用户其他账号上； - 如果 ccid 查出来的用户 ID 和用户反馈的都匹配不上；则再根据 IDFV 查询，看是否存在 ccid 变更的情况。
  6. 最后根据上面查询到的信息，做出处理：
  7. 绑定到其他用户账户的，提示用户切换账户
  8. 有充值订阅但是，用户状态或余额没有记录的，需要手动补单

大致的流程就是上面这样。属于明确的任务场景，打算封装成一个 Agent，来实现上面整个流程，输入目标，Agent 自己调用接口，获取网页内容，输出最终查询结果。

然后把这个流程输入到codex 或者 Workbuddy 中，告诉它让它实现一个 Agent。

过程中有需要不断确认的，再一一确认。

最后，用封装好的 Agent 实际走一遍流程，看是否符合预期，结果是否正确。

开发过程

第一步，把整个流程，描述给 Workbuddy，让 Workbuddy 封装 Agent，如下图：

会输出技术方案和关键决策，以及待确认的问题，如下图：

然后把待确认的问题描述清楚，继续下一步，这里需要注意，使用的工具，也需要指定清楚，比如什么浏览器，以及使用浏览器的方式（交互方式，比如是要直接 js 设置值，还是通过模拟用户点击的方式），否则 WorkBuddy 实现的不一定是自己想要的，如下图：

WorkBuddy 封装完成后，会提示验证功能，如果确认流程没问题，则可以用测试数据来验证真实功能，如下图，

然后在这个过程中，你会发现，如果不指定输出结果，它的输出结果不一定是你想要的格式，如下图，所以需要明确告诉 WorkBuddy，你要哪些数据，以什么格式输出，如下图：

大致流程就是这样，但其中其中还有很多问题需要注意，需要来来回来拉扯很多次，比如下面列出了几个：

遇到的问题：

问题 1：发现返回的数据跟查询的 ID 没关系，不知道为什么会返回这样的数据？

排查后发现，他做了一个查询订单列表查询不到数据时，兜底返回第一条数据的逻辑？？（好家伙，根据订单号查询订单，还要给个兜底，是只怕我太轻松了）。。。

问题 2：页面操作查询订单列表默认是没有交易 ID 的输入框的，是先点击 Expand，然后才会出现交易 ID 的输入框的，让他按照这个步骤来，但是他总是理解不了。

AI 在没有 Expand 的时候获取到交易 ID 的输入框，然后输入开始查询，但是 H5前端的逻辑是没有 Expand 的时候，不会提交这个值。。。就导致查询一直出问题，我说他没传交易 ID，他说传了。。。

问题 3：由于它自动化操作太快，填写完待查询数据后，马上发起请求，导致发起请求没有带上这个值。。。

问题 4：日期选择框的变化，或者方式不同，导致它操作错误，返回错误的数据？

问题 5：让他返回 IDFV 查询后的所有数据，IDFV 的查询很慢，他发起请求后没有等待结果返回，拿着 IDFV 发起前的结果直接回复了。。。

体验总结

怎么说呢，正常的需求开发，当需求描述明确后，基本都是一次完成90%，剩下的大概是没描述清楚或者没覆盖到了。但是 Agent 开发就不是这样，即使描述的很清楚的场景，实现时也会遇到各种各样的问题。比如：工具调用、权限配置、登录态同步等等。没有办法一次完成，只能在实现中不断完善。。。

总得来说，要封装 Agent，必须要熟悉业务，要能把具体的业务描述出来，并且把任务场景的所有场景都要覆盖到。

其次，要明确边界，要知道哪些是可以自动的，哪些必须手动或人工确认的。

然后，要明确输出，要明确自己想要的结果，是表格？还是简单的是否？或者一段文字结论？

过程中，会有很多要失败和异常，需要一步步完善，要有耐心，而且不能用人类的理解来要求 AI 理解同样的问题，要把问题和需求用 AI 能理解的方式来描述给它。

最后一定要小心编造数据的情况，必须要多次验证，不断完善；