开发者将OpenCode集成至工作流以优化AI生成JSON稳定性

背景

在开发基于 AI 的智能投标工具箱 OpenBidKit_Yibiao 的过程中，作者面临着一个典型的技术痛点：不同大语言模型（LLM）在处理复杂 JSON 数据生成时的能力差异与偏好冲突。

由于该软件是开源项目，支持接入任意模型，因此无法针对特定模型进行定向优化。在生成包含多层级结构和数组嵌套的 JSON 数据时，不同模型暴露出的问题各不相同。传统的解决方案是尝试序列化 AI 返回的 JSON，若失败则将报错信息反馈给 AI 进行自我修复，最多重试 3 次。虽然这解决了大部分问题，但仍存在小概率的失效场景：

1. 错误过多，3 轮修复不足以纠正。
2. 修复后的 JSON 虽然能序列化，但格式已偏离工作流所需的标准。
3. 极个别模型会直接删除报错部分，导致上下文丢失。

为了解决这一稳定性瓶颈，作者提出了一种被称为“邪修”的创新方案，即在现有工作流中集成 OpenCode 来处理需要深度理解与决策的复杂任务。

核心内容

作者的核心思路是利用 OpenCode 在代码生成与自我修复方面的高准确率，将其作为后端服务嵌入到投标智能体中，以替代或增强传统的 LLM 直接输出 JSON 的方式。

具体实施步骤如下：

1. 内嵌 Runtime：在项目内部嵌入了 OpenCode 的 runtime，并通过 HTTP 服务端点与其通信。
2. 配置代理：重写了 OpenCode 的 AI 服务商配置，使其直接代理到 OpenBidKit_Yibiao 的 AI 服务商，从而与主项目共用一套 AI 配置，无需额外维护模型连接。
3. 任务分流：将原本由 LLM 直接处理的、需要理解性决策的任务（如 JSON 格式校验与修复、全文一致性审计、原文覆盖率审计等）全部交由 OpenCode 处理。

这种架构设计极大地降低了代码复杂度，同时显著提升了系统的稳定性。

此外，作者还回应了关于为何不直接使用 Agent + Skill 模式的疑问：

• 上下文限制：Skill 模式适合轻量级项目，但面对长达百万字的投标文件，Agent 难以在单轮或多轮对话中有效处理如此长的上下文。
• 交互复杂性：投标文件生成步骤繁多，仅靠 Agent 的单轮对话无法完成，需要用户与 AI 频繁交互并记忆大量提示词。相比之下，集成到工作流（Workflow）+ GUI 中，用户只需通过界面操作，体验更佳。
• 缓存效率：经过优化的固定工作流（以 DeepSeek 为例）缓存比例可达 40%-70%，综合缓存率超过 60%。而通过 Agent + Skill 处理时，难以控制缓存命中率，导致成本增加。

作者还展望了未来 Agent 的潜在应用场景：语义化修改局部内容。即不让 Agent 处理全文，而是暴露接口，让用户通过自然语言提出修改需求（如调整目录结构），由 Agent 自动执行具体的 UI 操作或文件修改。

关键要点

• 技术痛点：开源 AI 应用中，多模型兼容性导致复杂 JSON 生成不稳定，传统“报错-重试”机制存在局限性。
• 解决方案：集成 OpenCode 作为专用处理单元，利用其代码生成与自我修复能力处理结构化数据校验。
• 架构实现：通过 HTTP 端点内嵌 OpenCode runtime，并代理主项目的 AI 配置，实现资源复用与低耦合。
• 任务划分：将“理解性决策”任务（校验、审计）交给 OpenCode，将“执行性任务”交给主工作流，降低整体复杂度。
• Agent vs. Skill：
  • Skill 适用于轻量级、短上下文场景。
  • Agent 在处理超长上下文（如百万字标书）时存在瓶颈，且难以控制缓存效率。
  • Workflow + GUI 更适合复杂、多步骤、需用户交互的长周期任务。
• 未来方向：探索 Agent 的语义化局部修改能力，通过自然语言指令驱动软件执行特定操作，而非全文重写。

意义与影响

这一实践为 AI 应用开发提供了新的架构思路，特别是在处理结构化数据生成和复杂逻辑校验时，单纯依赖 LLM 的直接输出往往不够稳健。通过引入 OpenCode 这样的代码辅助工具作为中间层，可以有效利用其在代码层面的精确性和自我修复能力，弥补通用 LLM 在特定格式约束下的不足。

此外，该案例清晰地界定了 Agent、Skill 和 Workflow 在不同场景下的适用边界。它提醒开发者，在处理长上下文、高复杂度任务时，固定工作流结合 GUI 可能比纯对话式的 Agent 更具稳定性和用户体验优势。同时，缓存效率的量化对比也为优化 AI 应用成本提供了重要参考。

这种“邪修”式的集成方案，展示了开发者如何利用现有工具链的特性进行创造性组合，以解决特定领域（如招投标）中的工程难题，具有较高的借鉴意义。