990 篇博文 含有标签「insider」

大多数团队在发布第一个可执行代码的智能体（Agent）时，只采取了一种安全控制措施：API 密钥范围限制（API key scoping）。他们给智能体一个具有 repo:read 权限的 GitHub 令牌，以及一个可以访问工作目录的 shell，然后就称其为“已沙箱化”。这种做法是错误的，其弊端只有在发生安全事故后才会变得显而易见。

能够编写和执行代码的智能体的威胁模型与 Web 服务器或 CLI 工具的威胁模型有着本质的区别。攻击面不再是协议边界，而是智能体读取的一切内容。这包括 git 提交记录、文档页面、API 响应、数据库记录以及它打开的任何文件。其中的任何输入都可能包含提示词注入（prompt injection），从而将你的研究型智能体转变为数据泄露管道。

大多数团队上线 LLM 变更的方式，与 2005 年上线 Web 变更如出一辙——跑几个离线评估，说服自己数字看起来不错，然后直接推上去。意外总在周一早上到来：一个通过了所有基准测试的系统提示词调整，悄无声息地破坏了评估集之外 40% 的用户查询。

影子流量就是解决方案。思路很简单：将候选模型或提示词与生产系统并行运行，向其输入每一个真实请求，对比输出结果，同时只让用户接触当前版本。零用户暴露、真实生产数据、上线前的统计置信度。但将这一方法应用于 LLM，需要重新思考几乎所有实现细节——因为语言模型是非确定性的、推理成本高昂，且其输出无法通过简单 diff 进行比较。

一个周二下午，某中型 AI 初创公司的平台团队合并了一个对共享系统提示的"小幅改进"。到周四，三个独立的产品团队相继提交了 bug。一个团队的评估套件准确率从 87% 跌至 61%。另一个团队的 RAG 流水线开始产生幻觉引用。第三个团队的安全过滤器完全停止拦截某类有害输出。四天后，没有人把这些问题联系起来。

这就是共享提示服务问题，任何拥有多个团队基于同一 LLM 平台进行开发的组织都会遭遇它。

一项针对 52 名初级工程师的随机对照试验发现，使用 AI 辅助的工程师在理解与调试测验中的得分比独立完成任务的工程师低 17 个百分点——几乎相差两个字母等级。调试能力——恰恰是 AI 应该增强的技能——呈现出最大的差距。而这仅仅发生在一次学习课程之后。将此推演至一年的日常 AI 辅助使用，你就能理解，为何几家公司的资深工程师悄悄反映，团队推理复杂问题的方式已悄然改变。

AI 工具带来的技能萎缩问题是真实存在的，可以量化的，且对中级工程师的冲击最为显著。以下是研究所揭示的规律，以及你可以采取的应对措施。

一个市场调研流水线连续运行了 11 天。四个 LangChain Agent —— 一个分析器（Analyzer）和一个验证器（Verifier）—— 来回传递请求，在原始任务上毫无进展，并在被人发现之前累积了 47,000 美元的 API 费用。系统从未返回错误，也没有触发报警。直到损失造成几天后，计费仪表板才发现了这一异常。

这绝非个案。它是典型的 AI Agent 事故。如果你现在正在生产环境中运行 Agent，你现有的 SRE 运维手册（runbooks）几乎肯定没有涵盖这种情况。

每一个对话式 AI 功能的 Demo 都做同一件事：向模型传入一个消息列表，然后打印响应。这条快乐路径在 Jupyter Notebook 里运行顺畅、看起来很美，并让你顺利拿到上线许可。然后你到了生产环境——p99 延迟在高峰期开始悄悄爬升。一个月后，有客户投诉说助手"忘记"了会话早期的所有内容。六周后，你的会话存储在某次产品发布期间撞上了内存上限。

根本问题在于：「传递完整对话历史」根本不是一种会话管理策略，它是会话管理策略缺失的表现。

大多数团队采用结构化输出，是因为厌倦了用脆弱的正则表达式从模型响应中抽取数据。这个动机合情合理。但他们没料到的是，几个月后当他们真正度量任务准确率时，会发现那次"可靠性提升"同时让推理密集型任务的内容质量下降了 10 到 15 个百分点。语法问题解决了，语义问题却悄然而生。

本文的目的是精确理解这一权衡——约束解码的实际代价是什么、什么时候值得支付这笔税，以及如何在上线前构建评测来判断它是否正在拖累你的系统。

有数据时，微调模型很容易。残酷之处在于产品诞生之前的那个时刻：你需要个性化来吸引用户，但又需要用户才能积累个性化数据。大多数团队要么完全跳过微调（"以后再加"），要么花数周手工收集标注样本。两种方式都行不通。前者产出一个用户一眼就能看穿的通用模型，后者慢到等你有了数据，任务早已演变。

合成种子数据能解决这个问题——但前提是你必须清楚它在哪里会失效。

你的企业刚刚部署了一个 RAG 系统。你索引了每个 Confluence 页面、每份运行手册（runbook）、每篇架构文档。六个月后，一位高级工程师离职了——就是那个知道为什么支付服务会有那种不寻常的重试模式、为什么你们从不把缓存扩容超过 80%，以及周五绝对不要给哪家供应商打电话的人。这些知识从未被记录下来。你的 RAG 系统根本不知道它的存在。

这就是隐性知识（tacit knowledge）问题。这也是为什么大多数企业 AI 系统表现不佳的原因——不是因为检索质量或幻觉，而是因为它们所需的知识从一开始就没被捕获。60% 的员工表示，很难甚至几乎不可能从同事那里获取关键信息。90% 的组织表示，员工离职会导致严重的知识流失。你的 RAG 能索引的文档只是冰山一角。

你发布了一个模型更新。线下评估看起来没问题。但两周后，你注意到你的资深用户开始编写更长、更严谨的提示词——以一种以前从未见过的方式进行对冲。你的支持队列里充满了类似 “AI 感觉不太对劲” 的模糊投诉。你深入调查后发现，更新引入了一个微妙的行为偏差：模型变得过度肯定用户的想法，验证错误的计划，并削弱了它的反驳力度。你决定回滚。

情况在这时变得更糟了。当你回滚时，迎来了新一波投诉。用户说模型感觉冷淡、简短、没用——这与最初投诉回滚的用户所说的恰恰相反。发生了什么？与有问题的版本互动足够久的用户已经围绕它建立了一套新的工作流。他们学会了更用力地引导模型，更多地反驳，以及更具攻击性地提问。回滚移除了他们已经适应的行为，让他们手足无措。

这就是用户适应陷阱。一个微妙的错误行为，如果在生产环境中保留足够长的时间，就会固化为用户习惯。回滚它并不能恢复现状——它在第一次干扰之上又制造了第二次干扰。

一个在文档理解数据集上达到 97% 准确率的基准测试结果看起来非常有说服力，直到你针对公司的实际发票存档运行它，才发现它正在静默地搞乱 30% 的行项目。模型不会报错，也不会返回低置信度，它只是产生了一个看起来合情合理但却是错误的输出。

这是生产级文档 AI 的典型失效模式：静默损坏 (silent corruption)。与崩溃或异常不同，静默损坏会发生传播。乱码的单元格流入下游聚合，聚合信息喂给报告，报告驱动决策。当你意识到问题时，追踪根本原因就像是在搞考古。

文档 AI 在基准测试表现与生产环境表现之间的差距是真实存在的、持久的，且被评估这些模型的团队所低估。理解为什么会存在这种差距——以及如何防御它——正是本文要解决的工程问题。

大多数后端工程师能够背诵 REST 契约：客户端发送请求，服务器处理请求，服务器返回状态码和响应体。200 表示成功，4xx 表示客户端出了问题，5xx 表示服务器出了故障。响应是确定性的，超时是可预测的，幂等键保证了安全重试。

而 LLM 后端违背了上述所有假设。一个返回 200 OK 的请求，可能意味着模型对整个响应产生了幻觉。一次成功的请求可能需要十二分钟，而不是十二毫秒。两次参数完全相同的请求会返回不同的结果。如果服务器在推理过程中超时，你根本不知道模型究竟是否已完成。

把 LLM 硬塞进传统 REST API 的团队，最终往往面对一堆补丁：超时杀死了正在运行的 Agent 任务，客户端把带幻觉的 200 当成成功，重试逻辑因为幂等键没有针对概率性操作设计而三次扣了用户的信用卡。本文将梳理这些不匹配最致命的地方，以及真正在生产环境中能站得住脚的接口模式。