Agent搭建实践与ReAct框架理解指南

Agent搭建记录与实战经验

今天正式开始使用Codex，在我的OpsAgent上搭建一个Web Agent功能。核心目标非常明确：将运维工作中那些重复且耗时的网页点击操作，交由自然语言指令来驱动执行。

在日常运维过程中，存在大量机械重复的网页配置任务，反复点击操作极其浪费时间。期望这个Agent能够理解我的自然语言指令，自主完成这些繁琐操作。

使用Codex时，必须养成一个习惯：每完成一轮对话，及时检查它实际执行了什么、如何实现的。今天我就踩了一个坑：Codex运行几轮后，我发现它并没有构建起基于LLM的核心能力，而是通过硬编码的逻辑判断来实现功能。这白白浪费了大量Token，尤其是在使用GPT-5.5之后，明显感觉Token消耗速度加快。

不过话说回来，我工作中实际需要的是固定的执行工作流（SOP），使用Playwright脚本也能实现。但这种方式不太符合当前发展趋势，且灵活性较差。因此，我现在的想法是：先搭建一个类似Browser Use的底层能力，未来遇到新的工作流时，直接让Web Agent执行一遍操作，成功后自动总结出对应的Skill或提示词，方便后续复用。这样就能省去手动分析DOM、编写代码构建的繁琐过程。

在实际搭建过程中，遇到了不少问题。例如，Codex最初设置的超时时间不合理，需要根据实际测试和网站响应速度逐步调整。再比如，它实现的人机交互功能——即敏感操作需要人工确认——会将当前网站的会话直接关闭，等待人类指令后又得重新开始。还有一个令人头疼的问题：搭建的功能尚不支持点击iframe内的元素。以上问题暂时都没有解决，原因很简单：额度用光了。这周剩余的额度仅剩4%，实在尴尬。

在采用Vibe Coding完成阶段性功能后，务必定期进行审查。可以让Codex生成一份Review-Report文档，详细说明做了什么、为什么这么做、如何实现以及如何权衡各种优劣。然后基于Review-Report阅读代码、运行测试，边学边做。但说实话，审查代码相当耗时。特别需要一个工具，能够自动分析代码、清晰呈现项目结构，让普通开发者快速理解。前两天看到Gemini在GitHub上上线了一个类似功能的工具，但看完介绍后，尚未真正尝试。

在搭建Web Agent的过程中，我更深刻地体会到之前的记录和调研非常有价值。Codex很强大，但用Agent去搭建另一个Agent时，必须明确告诉它采用什么样的思想——例如ReAct框架：接收到自然语言指令后，拆解任务，执行Web动作，解析DOM，再继续执行，形成循环。对于LLM的输入，需要使用Pydantic构建Schema来约束结构。总之，要学会理解AI是如何完成一项任务的。

ReAct框架核心理解与优化思路

我找了一个GitHub仓库浏览面试题，并自己进行了回答：

ReAct框架与传统Chatbot不同，后者仅停留在思考和对话层面。ReAct通过“推理→执行→反馈→循环”的机制，使Agent能够处理复杂任务，同时减少幻觉。具体过程是：LLM收到自然语言指令后，先解析指令，然后进入推理阶段——思考如何拆解任务。接着根据拆解后的任务调用对应的执行工具，工具执行完成后返回结果，LLM再根据反馈继续推理、继续执行，直到任务完成。

优势非常明显：减少幻觉，任务执行更加精确，擅长处理复杂任务，尤其适合需要任务拆解的Task。

短板同样不少：上下文会变得很长，Token消耗增多；如果初始决策方向错误，很容易陷入死胡同；还可能进入死循环；工具选择上经常出现错误；实际执行时还涉及安全风险。

针对这些不足，解决思路也很明确：

• 上下文压缩，分层构建记忆系统，按需加载记忆。具体可分为短期记忆、长期记忆和会话记忆
• 使用思维树（ToT）和自我反思（Self-Reflection）来解决初始决策错误问题——树形结构使Agent能够回溯，自我反思机制则实现自我优化
• 设定必要的结束约束，例如最长执行时间、最大执行步数、重试次数等，同时明确任务完成需要满足的判断条件
• 对工具进行分类，构建工具注册表，并设计路由机制
• 工具执行按风险等级分级，高风险操作需人工确认，执行前先进行Dry Run，所有动作留痕以便审计

经验总结与后续思考

“It ain't all good, but it ain't all bad either”——这句老话放在今天再合适不过了。

最近效率确实有些低下，还需要学习如何与AI相处，如何与自己battle。不要懒于思考，也不要停止思考。

做Agent应用开发，到底要不要了解Transformer、多模态模型、强化学习、模型微调等知识？目前还没有答案，但这些内容之后需要找时间认真研究。

继续加油，前路漫漫。