我的人工智能代理系统在四个不同的大语言模型提供商上运行着16个团队。两个月前，其中一个团队开始悄无声息地生成错误的政策决策。我在11分钟内就发现了这个问题。
不是靠 Datadog，也不是靠 Honeycomb，而是靠47行写入 SQLite 数据库的 Python 代码。
OpenTelemetry 目前正在制定大语言模型追踪的语义规范。这很好。但我六个月前就需要这个功能，所以我自己动手搭建了一套。以下是完整的配置方案。
简而言之：一个基于 SQLite 的审计追踪系统，用于多代理人工智能编排，记录每一次大语言模型调用、模型路由决策和偏见检测事件。338条审计记录和108个事件揭示了3起静默故障，而基于成本的监控完全无法发现这些问题。 整个系统仅包含4张数据表，运行在甲骨文云（Oracle Cloud）免费套餐的1GB实例上，取代了原本每月约200美元的可观测性工具支出。总实现时间：一个周末。
问题：在多个模型间盲目飞行
运行单个模型很简单——你只需查看输出即可。但在单一编排流水线中同时运行四个不同的大语言模型，会带来单模型架构从未遇到过的调试难题。 我将任务分配给克劳德奥普斯（Claude Opus，负责实现）、双子星3.1（Gemini 3.1，负责信息整合）、GPT-5.4（负责战略复审）和科德克斯（Codex，负责并行任务执行），并将它们组织成16个代理团队，按顺序相互交接工作。
面对四个模型和16个团队，你需要回答一些 print() 无法解决的问题：
- 哪个模型处理了哪一步
- 每一步耗时多久
- 输出结果是否被实际使用，还是被悄悄丢弃
- 路由决策的依据是什么
在自行开发之前，我评估了现有方案。LangSmith Teams：每月约400美元。自托管 Langfuse：需要配备2GB以上内存的 PostgreSQL 实例。OpenTelemetry 的生成式人工智能语义规范：仍处于实验阶段，尚无生产部署方案。
我需要的是今天就能用、能在1GB内存服务器上运行、且基础设施预算为零的解决方案。
第一步：四张表，一个数据库
实现多代理可观测性的最小可行数据结构包含四张表：一张用于原始调用日志，一张用于系统事件，一张用于路由决策，还有一张用于代理记忆。整个结构简单到可以装进你的脑子里——这种限制本身就是一项优势，而非缺陷。
CREATE TABLE audit_log (
id INTEGER PRIMARY KEY AUTOINCREMENT,
timestamp TEXT DEFAULT (datetime('now')),
action TEXT NOT NULL,
agent TEXT,
model TEXT,
input_summary TEXT,
output_summary TEXT,
latency_ms INTEGER,
tokens_in 免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
