背景

起因是：看群里一直说现在面试都是招 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 实际走一遍流程，看是否符合预期，结果是否正确。

体验总结

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

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

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

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

过程中，会有很多要失败和异常，需要一步步完善：
比如：BrowserUse需要说明是用自带的还是系统默认的，是否需要每次开启新的？

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