《别再裸奔调用 API 了！我如何用本地大模型+飞书 API，将 OpenClaw 调教成企业级情报助手？》

最近在折腾 OpenClaw 的企业级落地，发现虽然它很强大，但直接拿来给真实商业场景用，还是有不少坑。作为一个 9 年 Java 老兵，习惯了用工程化的思维去审视这些新工具。

周末帮一个做 ToB 销售的朋友，解决了一个他们团队长期存在的痛点：每天人工搜集、录入招投标信息。我用 OpenClaw + 本地大模型 + 飞书 API 的组合，撸了一套全自动的监控系统。

这篇文章不聊虚的，主要复盘一下在实现这个自动化数据流时，作为一名后端开发，我认为必须考虑的几个工程化关键点。

1. 核心架构：为什么一定要有“中间件”？

我的架构是 OpenClaw Agent -> 本地 Spring Boot API -> 飞书 API。

为什么不让 OpenClaw 直接调飞书？

• 兜底与重试：AI 的输出、网络请求都可能不稳定。在 Java 层可以轻松实现优雅的 try-catch、RetryTemplate 重试机制、以及对 AI 返回的“脏 JSON”进行格式化清洗。这些是保证系统 7x24 小时稳定运行的基石。
• 权限收敛：我不需要给 OpenClaw Agent 过多的飞书权限，它只需要能调用我本地的一个接口即可。所有敏感的 AppSecret、Token 管理都在 Java 服务内部，安全性更高。
• 业务逻辑沉淀：未来如果客户想把数据同时写入飞书和钉钉，或者在入库前根据金额触发一个邮件告警，这些复杂的业务逻辑都可以在 Java Service 层轻松扩展，而不是去修改 Agent 的 Prompt。

2. 飞书 API 的坑与优雅绕过

对接飞书多维表格时，大部分人会卡在权限上。特别是经典的 99991672 报错，根源在于：

• 应用权限没开对（需要 bitable:app）。
• 改完权限忘了 发布新版本！
• 没有把应用添加为表格的协作者。

3. AI 幻觉的工程化对抗

我们要求 AI 输出固定的 JSON Key，但它总有不听话的时候（比如把“项目预算”写成“预算”）。直接拿去请求飞书 API 必报错。

我的解决方案是写一个简单的“字段映射器”，把可能的“别名”强制归一化到标准的字段名上。

// 伪代码示例
private Map<String, Object> normalizePayload(Map<String, Object> rawPayload) {
    Map<String, Object> normalized = new HashMap<>();
    normalized.put("项目名称", rawPayload.get("项目名称") != null ? rawPayload.get("项目名称") : rawPayload.get("项目名"));
    // ...
    return normalized;
}

总结

AI Agent 给了我们强大的“意图理解”能力，但要把这种能力稳定、可靠地应用到企业生产环境中，传统的后端工程化思想依然是不可或缺的护城河。

这套系统目前已经可以稳定运行，后续会考虑把它封装成一个更通用的、可通过配置文件快速接入不同数据源的标准化服务。

对 AI 自动化落地感兴趣的同学欢迎交流。