861 篇博文 含有标签「insider」

在AI功能上线之前，你的连接池一直运行良好。登录正常，仪表板加载顺畅，CRUD操作以个位数毫秒的延迟稳定运行。然后团队部署了一个RAG驱动的搜索、一个Agent驱动的工作流，或者一个LLM支持的摘要端点——几个小时内，你的核心产品开始超时。数据库并没有变慢，你的连接池只是被一种它从未被设计来处理的工作负载吞噬了。

这就是LLM连接池问题，随着AI功能从原型走向生产环境，它正在影响整个行业的团队。解决方案不是"增加更多连接"。事实上，这通常会让事情变得更糟。

大多数采用 AI 编程智能体的团队，都会把第一周花在争论使用哪个模型上。他们用人为设计的例子对 Opus、Sonnet 和 GPT-4o 进行基准测试，痴迷于排行榜，最终选出一个。然后他们花接下来三个月纳闷，为什么智能体一直在重建错误的抽象、忽视他们的测试策略，以及反复询问该用哪个包管理器。

问题不在模型。问题在上下文文件。

每款 AI 编程工具——Claude Code、Cursor、GitHub Copilot、Windsurf——都会在每次会话开始时读取一个项目专属的 Markdown 文件。这些文件有不同的名字：CLAUDE.md、.cursor/rules/、.github/copilot-instructions.md、AGENTS.md。但它们的目的相同：告诉智能体那些无法通过阅读代码推断出来的信息。这个文件的质量如今比背后的模型更可靠地预测输出质量。然而大多数团队只写一次、写得很糟，然后再也不碰。

如果你经历过 2015–2018 年的微服务爆发期，那么 MCP 的现状应该会让你感到不安的熟悉。一个真正有用的协议出现了。它很容易搭建。每个团队都搭建了一个。没有人追踪什么在运行、谁负责维护、如何保障安全。不到十八个月，你就会盯着一张工程师私下称为"死星"的依赖关系图。

Model Context Protocol 正在沿着同样的轨迹发展，速度大约是三倍。非官方注册中心已经索引了超过 16,000 个 MCP 服务器。GitHub 上有超过 20,000 个公开仓库在实现它们。Gartner 预测到 2027 年 40% 的 agentic AI 项目将失败——不是因为技术不行，而是因为组织在自动化有缺陷的流程。MCP 泛滥正是这个问题的症状。

大多数采用 AI 编程工具的团队都会遇到同样的瓶颈。第一个月看起来像是成功案例：PR 吞吐量上升，Sprint 速率在攀升，工程经理正在制作幻灯片准备向领导层汇报。到了第三个月，事情悄然发生了变化。事故率开始回升。资深工程师在代码审查上花费了更多时间。一个简单的 Bug 修复现在需要理解一段团队中根本没人写过的代码。生产力的提升已经消失殆尽 —— 但衡量体系从未捕捉到这一点。

问题在于，大多数团队最先关注的指标 —— 生成的代码行数、合并的 PR 数量、消耗的故事点数 —— 对于 AI 辅助开发来说是错误的衡量单位。它们衡量的是产出代码的成本，而不是持有代码的成本。AI 让产出几乎变得免费，却让持有成本保持不变。

你的团队在周二执行了一次常规数据库迁移——将 last_login_date 重命名为 last_activity_ts，并扩展其语义以包含 API 调用。没有服务中断。测试通过。仪表盘更新。但你的 AI Agent——那个回答客户关于用户活跃度问题的 Agent——开始悄悄给出错误答案。没有报错，没有告警，没有堆栈跟踪。它只是自信地基于一个已经不存在的世界进行推理。

这就是 AI 工程中几乎无人关注的 Schema 迁移问题。你的 Agent 从工具描述、few-shot 示例和检索上下文中构建了一个隐式的数据模型。当底层 Schema 发生变化时，这个模型就变成了谎言——而 Agent 没有任何机制来检测这种矛盾。

大多数 AI 产品把单个功能做对了，却把产品整体做错了。搜索返回了合理的结果，摘要表述连贯，对话助手给出了合理建议。但当用户搜索"小团队最佳方案"、在侧边栏看到推荐、向助手追问后续问题，再阅读自动生成的选项摘要——而这四者相互矛盾时——没有一个功能还能让人信任。这就是环境 AI 一致性问题：不是孤立的幻觉，而是产品层面的矛盾。

这种失败模式足够隐蔽，以至于团队往往完全忽视它。单个功能的评估指标看起来还不错。搜索团队衡量召回率和精确率，摘要团队衡量忠实度，对话团队衡量任务完成率。但没有人衡量产品各 AI 功能之间是否在讲述同一个事实的同一个故事。

你的 AI agent 在推理、规划和生成自然语言方面表现出色。然后你把它指向企业的 SAP 端点，它接下来花了 4,000 个 token 试图理解一个 SOAP 信封。欢迎来到阻抗失配的世界——这个隐性税收把每一次企业 AI 集成都变成了 token 的焚烧炉。

这种失配不仅仅是 XML 与 JSON 的问题。它是 LLM 思维方式（自然语言、扁平的键值结构、简洁的上下文）与企业系统通信方式（深层嵌套的 schema、特定于实现的命名、分页游标以及数十年积累的协议约定）之间的根本冲突。与人类开发者只需阅读一次 WSDL 文档就可以继续工作不同，你的 agent 在每次调用时都要重新解析这种复杂性。

大多数团队发布第一个 AI 功能时都会使用最好的模型，因为演示（demo）就是在那上面跑的，而且没人有时间深入思考。接着第二个功能也用了同样的模型。然后是第三个。六个月后，每个功能的每次调用都指向了前沿层级（frontier tier）——而账单比实际需要的数额高出五到十倍。

令人不安的事实是，你的生产系统处理的 40%–60% 的请求根本不需要前沿级别的推理。它们只需要称职的文本处理。而购买称职的文本处理服务的成本要低得多。

2021 年，GPT-3 的价格是每百万 token 60 美元。到 2026 年初，同等性能的模型只需 0.06 美元。三年内降价 1000 倍。与此同时，企业 AI 支出增长了 320%——从 115 亿美元攀升至 370 亿美元。而在 AI 上花费最多的那些组织，恰恰正是从价格下降中受益最大的那批人。

这并不矛盾。这就是杰文斯悖论（Jevons Paradox），而它正在侵蚀你的 AI 预算。

你的模型写出了一份详细、结构清晰的分析报告。每个句子在语法上无懈可击，内部逻辑自洽。它引用的具体事实也都是准确的。然而结论却是错误的——不是因为模型缺乏得出正确结论所需的信息，而是因为它在开始推理之前就已经决定好了答案。

这不是幻觉。幻觉是模型凭空捏造事实。伪造问题更为隐蔽，在生产系统中也更难被发现：模型先得出结论，再构建一条听起来合理的证据链来支撑它。事实是真实的。综合分析却是谎言。

你的 AI 系统正在自信地回答关于一个已经不存在的世界的问题。不是因为模型坏了，不是因为检索失败了，而是因为每个生产环境的 AI 应用内部都有三个独立的时钟在以不同的速率运转——而没有人把它们同步起来。

这就是三时钟问题：墙上时钟（wall clock）、模型时钟（model clock）和数据时钟（data clock）各自运行在自己的时间线上。当它们发生偏移时，你得到的系统在技术上正常运行，但在实质内容上以错误日志永远无法捕捉的方式出错。

大多数构建 AI 代理的团队都在为成功而设计。他们衡量成功率，为代理自主处理 90% 工单而欢呼雀跃，然后在 UI 角落放一个"点击此处覆盖"按钮来应对剩余的 10%，之后便一走了之。

这个按钮不是安全网。它是一种包装成功能的责任。

失败模式不是代理崩溃，而是名义上负责的人类在崩溃发生时无法接管。AI 逐渐吸收了任务——每次一个工作流，每次一个边缘案例——直到过去处理这些任务的操作员已经六个月没碰过它，失去了上下文，却被迫应对一个他们已经无力管理的实时状况。这就是温备问题，它会悄无声息地积累，直到某次事故将其暴露出来。