722 篇博文 含有标签「insider」

一个长时间运行的智能体（agent）会话最初以 2K 上下文开启，现在却在为 40K token 的“死状态”买单。第三轮的检索结果、智能体早已跳过的目录列表、工具调用返回的 JSON 转储（即便其答案只是一个整数）—— 所有这些都在随后的每一次推理调用中如影随形，全额计费，并拖累注意力。这种模式在结构上与内存泄漏完全一致：无引用的数据无限制增长。但没有剖析器（profiler）能发现它，因为泄漏并不存在于进程内存中。它存在于对话历史里，而大多数智能体框架在发布时都没有配备回收机制。

成本同时体现在两个地方。token 账单呈二次方增长 —— 一个 20 步的循环，每一步贡献 1,000 个 token，累计产生约 210,000 个输入 token，而不是 20,000 个，因为之前的每一轮对话都会在后续的每一次调用中重新计费。而且模型本身也开始退化：当积累了 50K token 的噪声时，即使是拥有 1M token 窗口的模型，在实际任务上的准确度也会出现两位数的下降。你在花更多的钱，让模型更差地去思考它在三轮前就已经解决的问题。

周一，一位客户在 Slack 上询问你的助手如何启用某项功能，得到了清晰的回答，然后继续工作。到了周五，他们发邮件要求确认之前的决定，而运行在不同会话存储上的助手——完全不知道周一的聊天发生过——给出了截然相反的建议。客户不会针对两个产品提交两张工单，他们会针对你的 AI 提交一张工单，而且他们是对的。对他们来说，只有一个助手。你写了三个助手并将它们粘在三个特定渠道的会话存储上，这本该是你不该泄露的实现细节。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E8%B7%A8%E6%B8%A0%E9%81%93%E8%AE%B0%E5%BF%86%EF%BC%9A%E5%BD%93%E4%BD%A0%E7%9A%84%E6%99%BA%E8%83%BD%E4%BD%93%E5%BF%98%E8%AE%B0%E9%82%AE%E4%BB%B6%E5%BE%80%E6%9D%A5%E6%97%B6"]

这就是跨渠道记忆问题，它处于两个被团队低估的因素的交汇点：用户对连续性的假设有多强烈，以及渠道团队为了快速交付而编写各自会话存储的行为有多普遍。最近的行业数据清晰地揭示了这一差距——只有 13% 的组织成功实现了全渠道的完整对话上下文衔接。碎片化多渠道支持的 CSAT（客户满意度）仅为 28%，而真正的全渠道支持则为 67%。这 39 个百分点的差距并不是模型质量的差距，而是记忆架构的差距。

在上个季度的某个时候，你团队的一名工程师在 Slack 上发了一个帖子，开头是“模型变慢了”。他们展示了一张图表：你的助手功能的 p95 延迟从早上 7 点开始稳步攀升，在东部时间上午 10 点左右达到顶峰，午餐期间处于平台期，并在下午 5 点后悄然恢复。这种形态在第二天、第三天不断重复。团队追溯了他们的部署记录，指责了分词器（tokenizer）的更改，接着是上下文长度的退化，最后发现没什么是特别确定的。修复方案从未落地，因为 Bug 根本不在你的代码里。

顶尖模型提供商运行着共享的推理集群。当你的用户醒来时，北美其他地区也醒了，再加上欧洲的下午，以及每一家购买了相同 API 的公司的每一个内部工具。提供商端的队列深度翻倍，GPU 竞争加剧，你的 p95 延迟也随之翻倍——而你的代码库没发生一行代码变更。这是你技术栈中最可预测的生产事故，但几乎没有团队会为此建立仪表板。

打开本季度发布的任何 AI 功能的 PRD。注意那些形容词。助手应该是有帮助的 (helpful)。回复应该是自然的 (natural)。智能体应该理解 (understand) 用户的意图。摘要应该是准确 (accurate) 且简洁 (concise) 的。每一个这样的词都是团队放弃决策的地方。他们并没有决定这个功能要做什么。他们只是决定了在会议中如何向彼此描述这个功能，然后——在没人点破的情况下——悄悄地将实际的产品定义移交给了编写评估集的人。

这不是文档问题。评估集就是规格说明书。PRD 是一份在产品诞生前撰写的官方新闻稿。文档中模糊的形容词在评估集中变成了明确的行为断言，否则它们就毫无意义——模型会自行挑选一种解释并发布，而团队在三个月后才会发现，“简洁”对审核者、用户以及在上一个 Sprint 调整 Prompt 的人来说，含义完全不同。一个评估集薄弱的 AI 功能，其产品定义也同样薄弱。模型并没有失败。团队从未决定过成功意味着什么。

一名用户请求“一首关于 Postgres 复制的俳句”。模型返回了一首关于数据库的五行诗，其中提到了服务器和同步，听起来很有信心，读起来像模像样的英语，但并不是俳句。另一名用户请求“一个匹配 IPv6 地址但明确拒绝 IPv4 映射形式的正则表达式”。模型返回了一个匹配 IPv6 地址（包括它被要求拒绝的 IPv4 映射形式）的正则表达式，并用文字断言该正则符合规范。第三名用户请求“仅使用烹饪隐喻来解释 Monad（单子），不提及函数（function）或类型（type）”。模型给出了一个主要基于烹饪的解释，但其中使用了两次“函数”和三次“类型”。

这些都不是拒绝回答。这些也不是明显的幻觉。模型并没有说“我做不到”。它产生了一个自信、格式良好的响应，悄悄地放宽了请求中距离其训练分布众数最远的部分，而用户必须非常仔细地观察才能注意到。这种失效模式有一个值得使用的名称：强制符合偏见 (forced conformance bias) —— 模型将你的意图向典型答案“取整”，用户将结果视为忠实的响应，而本应捕捉到这一问题的评估套件本身也是从典型表述中提取的。

这在通常意义上并不是模型质量问题。模型正在做其训练推动它去做的事情。这是一个产品可靠性问题，如果评估团队的测试用例处于意图分布的众数位置，那么他们实际上只是针对其真实工作负载中简单的后半部分进行校准。

打开 OpenAI Python SDK 的源代码，你会发现一行安静的代码：DEFAULT_MAX_RETRIES = 2。Anthropic SDK 也采用了同样的默认设置。大多数 TypeScript SDK 也是如此。两次重试，指数级退避（exponential backoff），在连接错误、408、409、429 以及任何 5xx 错误时自动触发——这些都在你的代码看到失败之前就执行了。你没有配置它。你没有选择加入。你通常甚至不知道它的发生，因为你的应用记录的指标是 request_count（请求数），而不是 attempt_count（尝试数），并且你的追踪器（tracer）唯一能看到的 span 是 SDK 在最后一次尝试后关闭的最外层 span。

这在大多数情况下都没问题，直到出问题为止。如果在该 SDK 调用之上再添加一个应用级的重试装饰器——那种每个团队在遇到第一个 429 错误后都会写的代码——你就构建了一个 3x3 的风暴：SDK 尝试三次，你的包装层围绕 SDK 又尝试三次，在服务商降级期间，一个单一的用户请求会扇出为九次推理调用。服务商的账单会计算每一次尝试。而你的仪表盘只记录了一次。当最终有人进行账实对账时，那将是一场谁都不会喜欢的季度末谈话。

你公司最具战略意义的 AI 投资，可能是一位工程师在某个周五下午编写的一个 Slack 机器人。它回答“如何获取分级环境凭据”、“哪个值班人员负责认证服务”或“部署卡住时的运行手册是什么”，它节省的工程小时数比整个面向客户的 AI 路线图还要多——而后者占据了你四分之三的模型开销、安全审查队列以及发布沟通带宽。

组织架构图并未反映出这一点。OKR 文档也没有反映这一点。没有人是它的产品经理（PM），也没有人是它的工程经理（EM）。这个机器人之所以能生存下来，是因为构建它的工程师仍在回复 GitHub 上的 issue，在每一个面向客户的功能因六周的安全审查和发布就绪检查清单（之所以存在是因为客户可能会流失）而推迟发布时，它的价值正在悄然复合增长。

打开任何已经上线超过三个月的生产环境 AI 功能的系统提示词（system prompt）。数一数其中的负向条款——“不要”、“绝不说”、“避免”、“在任何情况下都不”、“你绝不能”。如果计数达到了两位数，你看到的就不是一个系统提示词。你看到的是一个坟场。每一块墓碑都标志着一个特定的用户投诉、一个特定的事故报告，或者一条来自利益相关者的 Slack 消息，因为他们看到模型做出了一些令人尴尬的事情。团队在表面打了补丁后就继续前进了，现在这个提示词读起来就像一份被强行嫁接了人格的法律免责声明。

负向提示词是代码异味（code smells）。并非隐喻意义上的，而是字面意义上的。它们在提示词工程中相当于吞掉异常的 try/except 块、没有文档的配置标志，或者是 2022 年留下的 // TODO: refactor this。它们在某种程度上有效，直到它们失效。而且它们所掩盖的失败模式，几乎总是比它们被添加用来压制的那个失败更有趣。

当你第一次将 MCP 服务器接入真实的生产系统时，你会发现教程中轻描淡写的一点：该协议赋予了智能体（Agent）能力，但并没有给工具服务器一个每个审计日志都要求的答案——这是代表哪个人执行的操作？ 你可以在不解决这个问题的情况下交付一个可运行的演示 demo，但如果不解决它，你无法向受监管的企业交付产品。而这两种状态之间的鸿沟，几乎完全是一个伪装成 OAuth 问题的分布式系统问题。

团队在这个鸿沟中寻求的解决方案，大致按尝试顺序排列，就像是把 OAuth 工作组十五年来一直警告的每一种反模式都游览了一遍。在 MCP 服务器环境中共享服务账号；将长期有效的个人令牌粘贴到配置中；或是乐观地认为“我们只需转发用户的会话 Cookie，让下游服务去处理就好”。每种方案在预发环境中都有效。但在安全审查第一次真正介入时，每种方案都会以不同的方式崩盘。

上个季度，一家金融科技初创公司的安全审核员在系统提示词（system prompt）中添加了四行内容。这次修改包含一条拒绝规则，旨在防止助手为公司未获得运营许可的司法管辖区提供具体的税务建议。这听起来很合理、范围明确且符合审计要求。该规则在周二上线。到周五时，评估套件显示在与税务完全无关的客户入职流程中出现了 7 个点的下降——模型开始对任何提及国家的提问都模棱两可，甚至包括“这个账户持有哪种货币”。产品团队撤回了修改。安全团队在下周以略有不同的措辞重新发布了它。三周后，同样的退化以不同的形式再次出现，而接下来的安全修改又破坏了另一个无关的流程。

这里的 bug 不在于措辞，而在于拒绝规则放错了位置。它被挤进了一个 2,400 token 的构件中，该构件还包含助手的对话语气、格式契约、任务指令以及其他六项策略条款——对其中任何一项的修改都是对所有内容的行为修改，因为模型无法分辨哪句话是策略，哪句话是风格。生产环境中的系统提示词之所以变成了一坨乱麻的单体，是因为三个正交的关注点伪装成了一个整体。没有将它们解耦的团队在每次修改时都在支付“集成税”。

周二下午，一个只有六行代码的系统提示词（system prompt）编辑出现在了一个 Pull Request (PR) 中。Diff 只是普通的英文。两位评审者扫了一眼新的措辞，觉得读起来更自然，于是点击了批准。PR 在不到一分钟内合并。到了周五，客服开始收到关于智能体的工单：它突然拒绝总结超过一定长度的文档，不再引用来源，并莫名其妙地在每句回复开头都加上 “Certainly!” —— 这种行为没人要求过，Diff 中也无法预见。

当一个花了十年时间学习如何评审代码的团队，在面对提示词这一产物时，竟然退化到了第一周的水平，结果就是这样。Diff 看起来 毫无害处，因为它读起来像英语，而人类正是用眼睛来审阅英语的。让代码评审发挥作用的规范 —— 运行测试、检查影响范围、对 “小改动” 保持适当的怀疑 —— 并没有悄然转化。措辞变好了，但行为变差了，直到用户发现之前，没人注意到。

三个团队正在查看同一个事件流，每个团队都有一个名为 session_id 的列，但每个团队对什么是“会话”都有不同的定义。计费（Billing）继承了来自认证库的 30 分钟空闲窗口。评估（Eval）从聊天机器人框架中继承了“直到用户说‘再见’或停止打字 10 分钟为止”的定义。记忆（Memory）则使用 UI 在用户点击“开启新聊天”时生成的线程 ID —— 而大多数用户从不点击这个按钮。三列数据，三种语义，一个汇总仪表盘，以及三个共用一个根因但互不相关的 Bug。

这就是会话边界问题（session boundary problem）。它看起来像是一个埋点琐事，但实际上是一个披着基础设施外衣的产品问题：一段对话在哪里结束？坦诚的回答是没有单一的标准答案 —— 计费会话、评估会话和记忆会话并不是同一种对象 —— 如果一个团队选择了一个默认定义并让另外两个团队继承它，那么他们交付的就是具有相同根因的计费纠纷、评估偏见和内存泄漏。