AI 智能体对话精选洞见

当 Pi、OMP-Pi、Codex、Craft Agent 同时存在时，手工改 JSON / YAML / TOML 会必然漂移。

洞见：做一个“一键写全套配置 + 健康检查”的工具，比继续堆文档更有效。不同系统支持的字段集合不一致，要用 adapter，不要假设“OpenAI 兼容 = 完全同构”。

Anthropic /v1/messages 与 OpenAI /v1/chat/completions 混用、API key 大小写、中转站只提供 GPT 却硬接 Claude，都会表现为“神秘 401 / 空回复”。

洞见：先用 curl 验证真实路由，再让 CLI 走同一条路；数据库 / 环境变量 / 高级 JSON 三层配置必须同步。

有的网关把最终答案塞进 reasoning_content 而不是 content；有的会拦 OpenAI SDK 的 User-Agent。

洞见：把“响应抽取”和“请求伪装”做成 provider adapter。健康检查应自动清理失效供应商，而不是等下次任务失败。

YOLO 裂缝检测多轮实验里，专项训练后召回反而下降，根因是标签污染（坑洞被标成裂缝），不是模型突然失灵。

洞见：先审计数据，再堆 epoch。delete / uncertain / keep 分层、按类统计 keep 率、用视觉模型做批量标签审计，比盲目 hard-positive mining 更划算。

低召回框并不都等于“模型漏检”，至少有：

1. 真漏检
2. 标签漏标
3. 框标偏

洞见：盲目把低召回样本再喂回去，会强化错误信号。先可视化复查，再决定清洗 / 重标 / 切图。

用推理模型做大规模标签审计时，reasoning token 会吃光预算，导致 content 为空。

洞见：max_completion_tokens 要显著抬高；并发调用必须有重试与错误分类。吞吐优化的前提是“先有输出，再谈加速”。

Obsidian vault + Digital Garden / Fumadocs 发布链路里，真正有效的是：

采集 → 清洗 → 结构化 → 发布 → 反馈

洞见：dg-publish 一类发布门禁会反向抬高笔记质量。Knowledge vault 的核心不是“存更多”，而是“输出倒逼输入”。

CLAUDE.md / 用户画像 / memory 文件决定了助手对你的默认假设。

洞见：把偏好、红线、验证标准写成可机读约束，比每次聊天重新解释更稳。这是轻量 memory system，不是聊天记录堆。

Issue 扫描后必须过一遍：是否已有 open PR、是否已被认领、是否功能等价已实现、是否维护者明确拒绝过同类改动。

洞见：小而贴合的文档 / i18n / 测试 PR，往往比“大而炫”的功能 PR 更容易进。跟 CI 与维护者反馈，比继续堆新 PR 更重要。

论文 Word 全流程、训练报告、PR 说明都受益于双轨交付：

• 净稿：可直接提交 / 合并
• 标记版：改动痕迹可视，便于复查

洞见：把“可验证”写进 tool use 默认协议。Agent 说完成不算完成，输出路径 + 命令 + 结果才算。

11. 配置故障循环要设止损。 同一模型切换连失败 3 次，就应降级到“换供应商 / 换 harness / 记录复现”，而不是继续重试。

12. 长会话归档只保留摘要与关键点。 原始 JSONL 是证据库，不是博客正文；公开内容最多抽 8–12 条洞见。

| 场景 | 优先看 | | --- | --- | | 多 harness 日常 | 1–3, 8, 11 | | 训练 / 数据 | 4–6 | | 知识管理 | 7–8, 12 | | 开源贡献 | 9–10 |

如果你在搭自己的 coding agent 工作流，建议把第 1、7、10、12 条固化成 skill 或检查脚本，而不是继续靠记忆。

更完整的统计与主题分布见 AI 智能体对话归档总览。