告别手动写代码：我的商品数据解析器 Agent 设计思路与方案

我们经常需要从各种来源抓取和处理商品数据。这些数据格式五花八门，编写解析代码是一项十分繁重但是缺乏技术含量的工作。为了解决这个问题，我设计并实现了一个 Agent，它可以帮助我们自动生成解析商品数据的代码，从而解放生产力。本文将深入介绍这个 Agent 的设计思路和方案。

背景与痛点

手动编写解析代码的痛点显而易见：

• 重复劳动: 针对不同的数据源，即使结构相似，也需要编写大量的重复代码。这就像不断地重复发明轮子，浪费时间和精力。
• 容易出错: 手动解析容易出现边界情况考虑不周，导致解析错误。一个小小的疏忽就可能导致数据处理的灾难。
• 维护困难: 当数据结构发生变化时，需要手动修改大量的解析代码。这就像在一个脆弱的系统中牵一发而动全身。
• 效率低下: 花费大量时间在编写和调试解析代码上，而不是专注于核心业务逻辑。 宝贵的时间被消耗在了重复性的技术细节上。

因此，我设想了一个能够理解数据结构和解析逻辑的智能助手，它可以根据用户提供的输入和期望的输出，自动生成可靠的解析代码。

整体设计思路 (State Diagram)

我的设计核心理念是构建一个迭代优化的流程，Agent 不仅能生成代码，还能通过验证和反馈不断改进其生成能力。 下面的状态图描绘了 Agent 的主要生命周期：

这个状态图反映了以下关键的设计思想：

• 清晰的初始化阶段: Init 阶段至关重要，它定义了后续操作的基础。通过明确解析器名称、类型和输入文件，Agent 能够理解用户的意图。

• 验证驱动的开发: Validate 阶段是循环的核心。通过执行和检查结果，我们能够发现问题并驱动后续的优化。

• 自动化与人工干预相结合: Auto Update 尝试自动解决问题，而 Manual Improve 则允许用户进行更精细的控制。这种混合模式能够应对不同程度的解析挑战。

• 迭代改进: Agent 不断地在 Validate、Auto Update 和 Manual Improve 之间循环，直到获得满意的解析结果。

详细的功能流程 (Flowchart)

为了更深入地了解 Agent 的具体工作流程，我设计了如下的流程图，详细描述了用户与 Agent 交互的各个命令及其执行过程：

这个流程图更详细地展示了 Agent 的内部运作机制和用户交互方式：

• init 命令的灵活性: 允许用户通过命令行参数快速初始化，也支持交互式输入，照顾不同用户的习惯。参数验证确保了初始化的正确性。

• validate 命令的智能化: 能够根据上下文判断是否需要用户提供额外信息，并能根据验证结果智能地生成改进提示 (prompt)。

• update 命令的多样性: 提供了多种更新解析器的方式，包括使用历史 prompt、交互式输入和命令行参数，满足不同的更新需求。

• improve 命令的持久化: 允许用户保存有效的改进 prompt，以便后续复用，提升效率。

• clear 命令的便捷性: 方便用户在调试过程中快速重置状态，避免历史信息干扰。

核心模块与实现细节

为了实现上述设计，我构建了几个核心模块，它们协同工作以完成解析代码的生成和优化：

• ParserGenerator: 这是生成解析器代码的核心模块。它的实现依赖于以下技术：

  • 大型语言模型 (LLMs): 利用 LLMs 的代码生成能力，根据用户提供的输入文件和目标 Schema 生成代码。Prompt 工程在此处至关重要，需要设计有效的 Prompt 指导 LLM 生成高质量的代码。

  • 混合方法: 根据不同的解析器类型， 需要精心设计不同的的 Prompt。

• Validator: 负责执行生成的解析器并验证其输出结果。它需要能够：

  • 动态执行代码: 在安全的环境中执行生成的解析器代码。

  • Schema 比对: 将解析结果与预期的 Schema 进行比对，找出缺失、类型不匹配或格式错误的字段。

  • 错误分析: 提供详细的错误信息，帮助用户理解问题所在。

• PromptGenerator: 负责根据验证结果生成改进的 Prompt。其核心功能是：

  • 识别错误模式: 分析验证结果中的错误信息，识别常见的解析错误模式。

  • 生成针对性 Prompt: 根据识别出的错误模式，生成能够指导 ParserGenerator 进行改进的 Prompt。例如，如果发现某个字段缺失，Prompt 可以指示 ParserGenerator 提取该字段。

  • 考虑上下文信息: 在生成 Prompt 时，需要考虑之前的 Prompt 和对话历史，避免重复或矛盾的指令。

• AgentShell: 提供用户交互的界面。它可以是一个命令行界面 (CLI)，也可以是一个图形用户界面 (GUI)。CLI 的优点是轻量级和易于自动化，GUI 则更易于上手和操作。我目前选择了 CLI，因为它更适合我的技术背景和目标用户群体。

未来展望

随着模型能力的不断增强，人工介入的成本会越来越低。目前我们解析一个中等复杂度的站点从代码生成到验证完成需要 1-2 小时，我相信半年之内这个时间可以缩短到半小时以内。
当人工介入降低到一个很小的范围时，我们会把整个流程平台化，在平台上操作即可完成代码的生成，校验和发布。

总结

通过这个商品数据解析器 Agent 的设计和实现，我希望能够帮助开发者摆脱繁琐的数据解析编码工作，将更多精力投入到更有价值的业务逻辑和数据采集中。这是一个不断迭代和完善的过程，目前至少帮助我们提效了 3 倍，我期待着在未来的工作中继续改进和扩展这个 Agent，使其能够更好地服务于数据处理的需求。
在实现这个 agent 后，正好 anthropic 发表了一遍文章，文章的内容我深以为然，我提炼出两点自己的切身体会

• 设计要简介，能实现功能即可，不要依赖框架（我不使用框架）
• 提供给 LLM 的工具函数和 Prompt 要精心设计，测试完善