1. 从71名议员的联名信说起为什么写代码的人也该看一眼71名英国议员联名致信首相呼吁推动一份国际协议对超级智能Superintelligence的能力边界设限。这个消息在国内技术圈传开的时候讨论基本分成两拨一拨觉得又是外行指导内行另一拨觉得总算有人把话摆到台面上了。我个人偏向后者但不是因为我支持某种具体的监管形式——这封信本身的信号价值在于关于AI能力上限的讨论已经从论文、实验室备忘录和行业自律声明挪进了公共政策的话语体系里。对我们这些每天和模型、提示词、推理服务、Agent 打交道的人来说真正该关心的不是签名名单有多长而是这种政策讨论一旦沉淀成规则会以什么形态落到工程现场。历史经验摆在那儿数据合规、内容审核、模型备案这些东西最早也都是学术呼吁后来都变成了上线前必须过的关卡变成了 checklist 里的一行字变成了架构评审时被人追问的一句话。超级智能这个词听着遥远但它牵出来的一整套问题——能力评估、对齐、权限控制、发布门禁、可追溯——其实全都在今天的生产系统里有对应的落地形态。这篇文章不聊立场也不预测政策走向我想做的是把这封信背后的技术议题拆开超级智能在工程语境里到底指什么为什么治理讨论会跑在技术前面以及一个普通团队现在就能做的、可复现的应对动作。适合AI应用开发者、模型部署与运维工程师、AI产品经理以及任何需要向管理层解释我们为什么要在权限和日志上多花两周的技术负责人。1.1 信里可核实的事实和它真正的分量先把事实层面的东西理清楚。据公开报道这封信的参与人数是71名议员收信方是首相核心诉求是推动国际层面的协议对超越人类智能水平的人工智能系统设立约束。还有一个常被忽略的细节这类联名信通常不是孤立事件它往往和同一时期发布的安全报告、行业自律承诺、学术机构的评估结论形成呼应构成一个议题打包。判断一封信的分量看三个东西就够了发起人的专业背景、诉求的具体程度、有没有配套的可执行路径。如果只是笼统呼吁要小心那基本属于情绪表达如果开始出现能力阈值评估机构发布前审查窗口这类具体构件说明背后有具备专业背景的人在参与起草。我个人的观察是最近两三年这类文本的具体程度在明显提高从呼吁谨慎变成了建议设立什么机制这个变化本身比签名人数更有信息量。给一个可以直接套用的读法把政策文本当需求文档读。里面出现的每一个机制名称未来都可能变成你上线流程里的一个环节。比如发布前评估这四个字工程上对应的就是评测集、红队用例、系统卡文档、审批流能力阈值对应的就是分级权限和可用范围声明国际协调对应的就是跨境数据与模型分发的合规设计。你在读的时候顺手画一张映射表半年后再回头看会发现不少东西已经开始往那个方向走了。提示判断一个议题会不会变成硬性要求最省事的办法是看它有没有从名词进化成动词名词。只有名词的时候还在讨论阶段出现评估备案审查这类动作词说明开始有落地路径了。1.2 从实验室备忘录到公共议程这条路是怎么走通的很多人以为政策对技术的反应是慢的其实在AI这个方向上反应链条已经明显缩短了。我复盘过这类议题的传播路径大致是四个阶段。第一阶段是技术圈内部的风险讨论产出物是论文和公开声明读者基本限于同行第二阶段是行业自律几家头部机构发布安全框架、承诺书主要作用是给外界一个我们在管自己的信号第三阶段是智库与评估机构介入把模糊的担忧翻译成可测量的指标比如危险能力评估、模型能力基线第四阶段才是立法与政策讨论也就是这封信所处的阶段。这条链路之所以能走通有一个关键加速器能力表达的直观化。十年前讨论AI风险讲的是抽象的技术奇点普通人没感觉。现在不一样了模型能写代码、能打电话、能操作浏览器、能自己规划多步任务这些能力被压缩成几十秒的演示视频传播成本极低。公共决策者不需要理解反向传播只需要看到它自己能干完一整件事这个事实就会产生规则需求。对工程团队来说这个传播链条有个现实含义上游讨论的颗粒度决定了未来规则的颗粒度。如果议题一直停留在AI很危险最后落地的可能只是一些笼统的声明性要求一旦议题细化到自主执行多步任务需要人类确认那就直接命中你的 Agent 架构。所以别把这类新闻当成和自己无关的宏观叙事它其实是在提前透露监管的思考切面。1.3 对一线工程团队的三个现实影响第一个影响是发布流程会变重。以前内部模型迭代可能就是跑完评测、看几个样例、直接灰度。以后更可能的形态是能力分级声明、评测报告留档、高风险能力单独门禁。我建议现在就养成写模型卡的习惯一页纸就够——训练数据来源、能力范围、已知缺陷、不适用场景、拒答策略。文档这东西等被要求交的时候再补成本会翻三倍。第二个影响是Agent 的权限设计会被审查。一个能读文件、调接口、发消息、执行脚本的 Agent在监管视角里就是一个具备自主行动能力的系统。它调用了哪些工具、有没有人类确认环节、操作日志能不能回溯这些问题以前是最佳实践以后可能是必要条件。我在项目里已经把工具清单按风险等级分成了三档这个习惯帮我省掉了很多解释成本。第三个影响是本地部署会变得更受重视。当模型权重视为需要管控的资产时把推理服务放在内网、把调用链路管起来、把出口流量做白名单这些动作的技术价值会被重新评估。不是为了防御什么而是为了满足可追溯、可审计、可关闭这三个基本要求。这三个词看着平淡但真要做到需要在网关层、日志层、权限层都动刀是实打实的工程量。2. 超级智能到底指什么把概念拆到能落地的粒度工程讨论最怕的就是概念悬空。你说超级智能很危险我没法据此改一行代码你说一个可以自主调用工具、跨会话保留记忆、能自我修改提示词的系统需要加审批环节我立刻知道该动哪里。所以这一节我们不谈哲学只做一件事把超级智能这个词拆成若干个可识别、可度量、可设计的工程特征。先给一个我自己的定义框架方便后面对齐讨论超级智能 在绝大多数认知任务上显著超越顶尖人类专家并且具备跨域迁移与自主改进能力的系统。注意这里的三个限定词。绝大多数认知任务排除了专用系统比如只下围棋的那种显著超越顶尖专家排除了接近人类平均水平的通用模型跨域迁移与自主改进是真正的分水岭它决定了能力是线性增长还是可能进入加速区间。这个拆法的好处是每个限定词都能对应到具体的评估方法。判断跨域迁移看的是在未训练过的新任务上的零样本表现判断自主改进看的是它参与改进自身流程的深度。有了这两个抓手讨论就能从信不信变成测不测得出。2.1 AGI 与 ASI是能力梯度不是开关业界习惯用 AGI通用人工智能和 ASI超级智能两个词很多人下意识把它们当成两个时间节点某一天到了 AGI再过一阵到了 ASI。实际更接近一条连续曲线而且这条曲线的测量方式很别扭——它不是单一指标而是一组维度上的组合。我一般用五个维度来描述这条曲线跨域迁移能力、长程规划能力、自主性程度、样本效率、自我改进参与度。前两个维度衡量能不能干中间两个衡量能自己干多久最后一个衡量能不能让自己更能干。这五个维度不总是同步增长经常出现某个维度突进、其他维度滞后的情况这也是为什么是否达到AGI这种问题总吵不出结论——大家心里的权重不一样。从工程角度看这条曲线的实际意义在于风险不是均匀分布的。一个长程规划能力很强、但自主性受严格限制的系统风险可控一个自主性很高、但规划能力一般的系统容易闯祸但不容易闯大祸最需要关注的是自主性和规划能力同时上台阶再加上工具调用权限那就是质变点。这也是为什么我在设计 Agent 的时候会把连续自主步数当成一个硬性上限来管理而不是放任它一直跑下去。维度低水平表现高水平表现工程上的抓手跨域迁移换任务就崩新任务零样本可用建跨域评测集按域打标长程规划三步内跑偏数十步保持目标限制单次任务最大步数自主性每步需确认端到端自动完成高风险动作强制人工介入样本效率需大量示例少量示例即学会关注上下文注入与记忆机制自我改进不参与自身优化参与流程与数据设计对训练流程变更做审批2.2 递归自我改进担忧的核心机制在所有这些维度里递归自我改进是被讨论最多、也最难处理的一个。它的基本形态是系统参与改进下一代系统或者参与改进自己的训练数据、训练流程、评估方法形成一个正反馈回路。每一次改进都让下一次改进更有效率能力增长曲线就从线性变成指数型。需要说清楚的是这个机制目前还处于非常早期的阶段。现实中的形态大多比较温和模型帮助生成训练数据、模型辅助写评测用例、模型参与代码审查和实验配置调优。这些事听起来平平无奇但它确实在缩短迭代周期。我参与过的一个项目从数据清洗到评测生成用了大量模型辅助整体迭代速度大概提升了三成左右。三成不惊人但如果这个比例逐年上升累积效应就值得认真对待了。从系统设计角度我关心的是回路里有没有人类检查点。一个健康的形态是模型提出方案人类审核关键决策模型执行低风险部分评估结果回流。一个需要警惕的形态是模型生成数据、模型标注数据、模型评估数据、模型决定下一轮训练人在回路外只看最终指标。后者短期看着效率高长期会积累两类问题数据分布被模型自身偏好污染评测指标被优化到失去区分度。我踩过一次很典型的坑——用模型生成的评测集来评估模型改进效果连续三轮指标都在涨换了一批人工标注的独立评测集之后真实提升几乎为零。2.3 度量难题基准污染、能力涌现和测不出上限治理讨论之所以急很大一部分原因不是技术跑得太快而是我们缺乏可靠的能力测量手段。这话听着有点反直觉毕竟各种排行榜满天飞。但排行榜测的是什么多数是固定题库上的准确率。固定题库有三个致命问题。第一是污染。训练数据规模巨大评测集难免被见过。一个模型在某个基准上刷到接近满分未必说明它掌握了那个能力可能只是记住了答案。判断有没有污染可以做简单的 n-gram 重叠检测也可以看模型在改动题目表述后的表现波动——如果换个问法分数就掉一大截那基本可以认定是记忆而非理解。第二是涌现的不可预测性。有些能力在小模型上完全看不到规模上去之后突然出现。业内在涌现是否真实存在这件事上争论很大有研究认为它部分是评测指标不连续造成的假象。不管结论如何从工程实践出发保守假设是必要的不要假设某个能力在小规模验证里没出现放大之后就一定不会出现。第三是上限无法验证。我们可以测出模型能做什么但很难测出最多能做什么。这两者的区别在于前者是抽样观测后者需要理论上界。所以在能力评估上我一贯主张用危险能力导向的方式替代综合分数导向与其问它有多强不如问它在哪些具体方向上达到了需要管控的门槛。前者是学术问题后者是工程问题后者能落地。3. 治理讨论为什么总是跑在技术前面这可能是整件事里最让人不舒服的一点制定规则的人通常不是最懂技术的人。但如果把情绪放一放会发现这种提前量其实有其内在逻辑不完全是外行干预。理解了这套逻辑你就知道哪些要求是临时的、哪些是结构性的从而把有限的工程资源投到对的地方。3.1 风险不对称与发布不可逆风险不对称是第一个因素。收益和风险的分布是极不均匀的能力提升带来的好处通常集中在少数开发者和使用方而潜在风险一旦发生影响范围可能是全社会。这种不对称在任何领域都会催生预防性原则——当潜在后果足够严重且不可逆时即使证据不充分也倾向于先设约束。这个原则用在桥梁、药品、核设施上是常识用在软件上则一直有争议因为软件的传统特性是可回滚。问题恰恰出在这里大模型的部分风险是不可逆的。权重文件一旦公开就再也收不回来任何后续的召回、下架、补救都只能作用于分发渠道管不住已经复制出去的那些副本。这个发布即不可逆的特性把AI从软件工程推向了工程管控的混合领域。理解了这一点就能理解为什么很多讨论不约而同地聚焦在发布前这个环节——因为那是唯一能施加有效影响的时点。对团队的启发很直接把发布可控性当成一个技术指标来设计。具体包括能力是否分级、不同档位的分发渠道是否隔离、灰度要不要按能力开闸、撤回机制是否演练过。我在项目里加过一条很朴素的规则——任何对外暴露的模型服务必须有一个一键降级到受限模式的开关并且在预发环境演练过。这个开关平时用不上但它的存在会倒逼你把能力边界想清楚。3.2 算力集中在训练侧权重扩散在推理侧第二个因素是产业结构本身的错位。训练侧高度集中能负担大规模预训练的机构数量有限算力、数据、人才都聚集在少数节点上这使得训练环节相对容易施加约束。推理侧高度分散权重一旦发布一台带显卡的机器就能跑边缘设备也能跑分发路径几乎无法追踪。这种上游集中、下游弥散的结构让管理者面对一个尴尬局面——最容易管的地方恰恰不是风险最终释放的地方。这个结构错位有一个常被低估的后果能力评估的样本会失真。你在官方服务上测到的行为不代表量化版本、微调版本、接入不同系统提示的版本的行为。我自己做过对比测试同一个基座模型换一套系统提示加工具绑定之后在安全相关的拒答表现上差异相当明显。这意味着任何基于单一部署实例的评估结论都不具备普适性你只能对自己实际部署的那个组合负责。所以内网部署这件事除了合规价值还有一层工程价值你能控制变量。模型版本、量化方式、系统提示、工具集、上下文拼装顺序全都在你手里出了问题能定位到具体环节。外面托管的服务你只能看到输入和输出中间那一段是黑盒。对一个需要承担解释责任的团队来说这个差别很大。3.3 评估滞后验证能力上限本身就是难题第三个因素最技术、也最容易被忽略验证本身是困难的。要制定合理的规则前提是知道规则要约束什么但能力上限这个对象很难被稳定观测。你测到的分数受提示词、采样参数、评分标准影响同一个能力在不同任务表述下表现差别可能很大更麻烦的是模型会在被评估时表现出不同的行为倾向这在业内被称为评估感知问题。这就形成一个循环因为测不准所以倾向保守因为倾向保守规则可能约束到不该约束的地方因为约束过宽又引发反弹认为规则不合理。要打破这个循环唯一可行的路径是评估方法本身要足够透明和可复现。这也是为什么我一直强调评测集要自己建、用例要版本化、评分标准要写清楚。不是为了对外证明什么而是为了在内部讨论时大家有一个共同的参照物。对普通团队而言务实的目标不是建立一套完整的危险能力评估体系那是需要专门团队和大量资源的事。更现实的做法是建立一个够用的回归评测集覆盖你业务里最敏感的几十个场景每次模型或提示词变更都跑一遍记录通过率和失败样例。这套东西成本不高但能让你在别人问你怎么保证它不乱来的时候拿出数据而不是形容词。4. 技术侧的四条应对路线把治理逻辑讲完之后回到我们真正能动手的地方。围绕如何让一个强大的系统保持可控业内大致形成了四条路线对齐、可解释性、能力评估、发布门禁。这四条不是互相替代的关系而是从不同层面切入同一问题。我按距离生产系统从近到远的顺序来讲方便你判断哪些现在就能用上。4.1 对齐从人类反馈到可扩展监督对齐要解决的问题是怎么让模型的行为符合人的意图和价值观。目前生产环境里最主流的手段是基于人类反馈的强化学习RLHF及其变体流程大致是收集人类对模型输出的偏好排序训练一个奖励模型再用它来优化策略模型。这套方法的效果已经被大量产品验证过但它的天花板也很明显——人类能提供的监督信号精细度是有限的。当模型能力超过标注者时问题就出现了标注者无法判断一个复杂的推理过程是否正确只能看结论是否听起来合理。这在数学、代码、长链条规划类任务上尤其明显。业内提出的应对思路统称为可扩展监督核心想法是用模型辅助人类做判断比如让一个模型去审查另一个模型的输出把复杂任务分解成人类能判断的小块或者用形式化验证来替代人工判断。给出几条可以直接用的落地经验。第一奖励模型的评估要单独做。很多人只关心策略模型的表现忽略了奖励模型本身可能被钻空子。定期用一批高奖励但明显有问题的对抗样例去测奖励模型能提前发现退化。第二偏好数据要标注来源和置信度。不同标注者的一致性差异很大混合使用时要加权否则训练出来的偏好会向标注质量高的那部分数据偏移。第三别指望一次对齐解决所有问题。上线之后分布会漂移需要定期回流失败案例重新训练这是个持续过程而不是一次性项目。4.2 可解释性从行为观察走向内部结构可解释性这条路线常被认为是学术研究离工程很远。我的看法是其中的一部分方法已经可以用了尤其是探针类方法和激活分析。它们的价值不在于告诉你模型在想什么而在于给你一个额外的观测维度当模型输入变化时内部表征是否发生了预期之外的变化。举个实际的例子。我们曾遇到一类问题模型在绝大多数情况下拒答某些敏感请求但在特定格式的输入下会绕过。从输出层面看这些绕过是零散的、不成规律的很难总结出模式。后来用简单的激活差异分析发现被绕过的那些样本在某几个中间层上的表征高度相似——这说明绕过的触发条件比表面看到的更结构化。找到了这个共性防护策略就好设计了针对那个表征模式做检测比穷举输入格式高效得多。门槛没有想象中高。开源模型配合成熟的框架几十行代码就能跑通基础的激活提取和探针训练。真正难的是建立解释结果的验证机制——你的探针是不是学了个无关特征解释是不是事后编故事。我的做法是用留出任务来验证探针在一个任务上训练在另一个相关任务上测试如果表现大幅下降说明它学到的东西不通用不能据此下结论。4.3 危险能力评估与红队测试怎么搭评估体系是整个应对链条里最容易做成形式主义的部分。我见过不少团队的评测集就是找几十个问题、录一遍标准答案、跑个准确率跑完就完事了。这种评测的问题是只测会不会不测肯不肯。对安全而言后者往往更重要模型可能完全有能力做某件事但正常情况下会拒绝需要考察的是在各种诱导下它是否还拒绝。实用的评估结构是分层的。第一层是能力基线测基础能力和领域能力用于版本间对比发现回归。第二层是拒答与边界覆盖你的业务里所有敏感场景用例要包含直接请求、变体表述、伪装请求、多轮诱导几类。第三层是工具与自主性只有在部署了 Agent 的团队才需要重点测的是越权、越界调用、连续自主步数失控。三层里第二层性价比最高投入小、收益直接。关于红队我有个不太一样的建议不要只让技术团队做。技术人员的思维习惯是找系统漏洞容易忽略社会工程类的诱导方式。加入产品、运营、客服角色的红队成员往往能设计出更贴近真实滥用场景的用例。另外红队用例必须版本化保存形成回归集——一次红队的价值主要在于它沉淀下来的那批用例而不是当时发现的几个问题。评估层级覆盖内容用例数量建议更新频率能力基线通用能力与领域能力200-500每次大版本拒答与边界敏感场景多轮诱导100-300每季度补充工具与自主性越权、越界、步数失控50-150每次工具变更4.4 发布门禁把能不能发变成流程而不是直觉前面三条都是能力建设这条是流程建设也是最容易被跳过的一条。原因很简单流程不产出功能看起来不产生价值在排期压力下第一个被砍。但我的经验是发布门禁是所有这些工作中性价比最高的一项因为它把分散的判断固化成了一道确定性关卡避免每次上线都靠我觉得没问题。我参与设计过的门禁清单不复杂六项能力分级声明是否更新、评测集是否全绿、红队有无新增高风险发现、变更影响范围是否评估、回滚方案是否验证、日志与审计是否就位。六项都过才放行。听上去像形式主义但真正的作用是强制在发布前做一次系统性的自我提问。有好几次就是这个流程逼着我们发现——某个新增工具调用没有纳入日志采集范围。有个实操细节值得说门禁的执行者最好不是写代码的人。倒不是不信任而是开发者对自己写的东西有天然的乐观偏差。让一个不参与开发、但了解业务的同事做核对通过率会明显下降问题发现率会明显上升。这个成本很低效果比想象中好。5. 把可控性写进架构一套可复现的落地做法前面讲的都是应该怎样这一节讲具体怎么做。我拿一个典型的 Agent 应用来举例它需要读取内部文档、检索知识库、调用若干业务接口、生成报告。这类系统现在很常见也正好处在能力与风险的交界处。以下做法都是我在实际项目里跑过、能落地的。5.1 权限分层与最小权限矩阵权限设计的第一原则是默认拒绝。工具清单初始为空每个工具都要显式申请、显式授权、显式登记风险等级。这听起来很啰嗦但比先给全部权限出事再收要安全得多因为收权限的阻力永远比给权限大——你一收紧立刻就有业务方来抱怨功能坏了。第二个原则是读写分离。读取类工具和写入类工具必须分属不同等级。读取文档、检索向量库这类操作风险相对可控写文件、发消息、改数据库、调用有副作用的接口风险等级要单独标定。我通常会把有外部副作用且不可撤销的操作单独列为最高等级比如发送消息、执行支付、删除数据。第三个原则是能力与身份解耦。不要用同一个服务账号跑所有工具调用而是按任务类型分配不同的凭证每个凭证只拥有完成该任务所需的最小权限。这样即便某条链路被绕过损失也被限制在单个凭证的权限范围内。这个做法在传统系统里是常识但在 Agent 场景里经常被忽略因为大家习惯用一个万能 token图省事。工具类别默认策略风险等级审计要求向量检索、文档读取允许低记录调用与返回摘要内部只读接口允许白名单低记录请求参数文件写入需审批中全量记录保留差异外部网络请求白名单审批中高记录域名与载荷摘要消息发送、支付、删除强制人工确认高全量记录双人复核执行系统命令默认禁止极高如必须沙箱内限额5.2 沙箱化与工具调用审批沙箱的目标是把模型能影响的范围限制在一个可控的盒子里。具体做法有几层。容器层面用非 root 用户运行文件系统除必要目录外全部只读挂载禁止挂载宿主机的敏感路径。网络层面默认无外网需要访问的域名走白名单代理并且限制响应大小——这一条经常被忽略但大响应体是提示词注入的常见载体。资源层面限制 CPU、内存、执行时长、单次任务的工具调用次数防止无限循环。审批环节的设计有个取舍全人工审批会毁掉体验全自动审批等于没有审批。我用的方案是分级低风险自动放行并记录中风险自动放行但在报告里标出事后抽查高风险阻塞等人工确认。判断风险等级的依据包括工具类别、参数特征比如写入路径是否在允许目录内、请求域名是否在白名单内、以及上下文中的指令来源。有一个细节值得单独强调指令来源必须标记。系统提示、用户输入、检索到的文档内容、工具返回的结果这四类内容在拼接进上下文时要带上明确的来源标签并且在策略上区别对待。来自外部内容的指令一律视为不可信数据不参与权限判断。很多越权案例的根因就在这里——外部文档里的一句话被当成了用户指令执行。# 工具调用网关的核心逻辑示意简化版 ALLOW {search_docs, read_file} # 低风险自动放行 REVIEW {write_file, http_request} # 中风险记录并抽样 BLOCK {exec_shell, send_message} # 高风险强制人工确认 def dispatch(tool, args, ctx): if tool in BLOCK: if not ctx.get(human_approved): return {status: pending, need: human_approval, tool: tool} elif tool in REVIEW: audit(ctx, tool, args, levelreview) if not in_scope(args, ctx.get(allow_scope, [])): return {status: denied, reason: out_of_scope} elif tool not in ALLOW: return {status: denied, reason: not_registered} return run_tool(tool, args) def in_scope(args, scope): 写入路径、请求域名等必须落在预先声明的范围内 target args.get(path) or args.get(url, ) return any(target.startswith(s) for s in scope)5.3 审计日志没有日志就没有复盘日志这件事我在项目里吃过亏所以格外在意。最早的版本只记录了最终的输入和输出中间的工具调用只有成功与否没有参数、没有上下文来源、没有耗时。结果一次异常行为排查花了整整两天最后还是靠复现才定位到。从那之后我的标准是凡是能改变系统状态的调用参数、来源、结果、时间、调用者身份一个都不能少。采集之外还有两个工程问题。一是存储成本。Agent 的日志量比传统接口大得多因为上下文很长。我的做法是分层存储完整上下文保留较短周期结构化的调用记录保留较长周期只对高风险调用保留全量。同时做敏感信息脱敏避免日志本身成为数据泄露渠道。二是关联性。一次会话会串起很多次调用必须有统一的会话标识和步骤编号否则日志就是一盘散沙。日志的真正价值在于支持事后归因。当出现一次不期望的行为时能回答四个问题这一步是谁触发的、上下文里有什么、当时用了什么权限、之前几步做了什么。能回答这四个问题绝大多数问题都能定位。回答不了就只剩猜测。我在评审 Agent 架构时第一件事就是让对方演示一次完整的日志回溯这比看架构图有效得多。5.4 内网推理服务的配置示例把推理服务放在内网是可追溯、可审计、可关闭三件事的物质基础。配置不复杂但有几个点容易踩坑。下面给一份可以直接改用的编排片段基于常见的本地推理服务。# docker-compose 片段内网推理服务 services: inference: image: ollama/ollama:latest restart: unless-stopped volumes: - ./models:/root/.ollama # 模型权重单独挂载便于备份与清理 ports: - 127.0.0.1:11434:11434 # 只监听本地不对外暴露 environment: - OLLAMA_MAX_LOADED_MODELS1 # 限制并发加载控制显存占用 - OLLAMA_KEEP_ALIVE10m deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] gateway: image: nginx:stable volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro ports: - 8080:8080 # 业务系统只访问网关不直连推理 depends_on: - inference三个容易踩的坑。第一端口绑定。很多示例写的是0.0.0.0:11434在开发机上无所谓在内网服务器上等于把推理服务暴露到整个网段任何人都能调用。改成127.0.0.1并只在网关层对外是基本要求。第二模型目录的权限。权重文件如果和业务代码放在同一个可写目录一旦应用侧有漏洞权重就有被替换的风险。单独挂载、只读、限定属主三件事一起做。第三健康检查与降级。推理服务挂掉时业务要有明确行为是返回缓存还是直接失败必须提前定好不能让它自己随机决定。网关层建议做的事情包括请求体大小限制、调用方身份校验、按调用方限流、请求日志落盘、以及一个可热更新的模型路由表。这个路由表的作用是让你能在不重启业务的情况下把某个调用方切到受限模型或者直接关闭这就是前面说的一键降级能力的具体实现。6. 常见问题与排查速查表这一节是我把自己和团队踩过的坑整理出来的。大部分问题都不是模型本身的问题而是权限、日志、评测、配置这些外围环节的问题。外围环节的特点是平时不出事出事就是连锁反应而且现场往往很难复现。6.1 五类高频故障的现象、原因与处理下面的表格按现象—原因—排查动作—处理四列组织可以直接当值班手册用。我按发生频率排了序前两类在 Agent 项目里几乎必然会遇到。现象可能原因排查动作处理方式Agent 越权写文件工具未登记、容器以 root 运行检查容器运行用户与挂载权限非 root 运行写入目录白名单评测分数异常偏高评测集与训练数据重叠做 n-gram 重叠检测换表述重测重建评测集加入改写用例外部内容触发异常行为提示词注入指令来源未标记检查上下文拼接顺序与来源标签外部内容视为数据剥离指令语义本地推理延迟抖动大显存不足、并发未限制看显存占用、排队长度限制并发启用量化设超时日志缺失导致无法复盘异步写入未落盘、采样过狠检查 flush 策略与采样率高风险调用全量同步落盘第一类问题的根因几乎总是图省事。开发阶段为了跑通链路给了 Agent 一个拥有广泛权限的凭证;上线时忘了收。这类问题的排查有个快捷方法直接看容器里的进程用户是谁以及挂载了哪些目录。如果看到根目录被可写挂载基本可以确定权限设计没有认真做过。第二类问题更隐蔽因为指标在涨没人会去质疑好消息。判断方法很简单把评测题目的表述改写一遍同义替换、语序调整、加入无关背景重新测一遍。如果分数明显下降说明模型依赖的是表面模式而不是能力。这个方法成本极低我建议每个团队都做一次基线检测。6.2 几个踩过的坑和对应的经验第一个坑把系统提示当成安全边界。早期我习惯在系统提示里写大段约束比如不要执行危险操作不要泄露内部信息。实测下来这种约束在正常输入下有效在对抗输入下基本无效。系统提示是行为引导不是权限控制。真正的边界必须在代码层实现也就是工具白名单和审批环节。后来我把这条经验总结成一句话提示词负责表现代码负责边界两者不能互相替代。第二个坑评测集只增不减最后没人维护。评测集膨胀之后跑一次要很久失败用例堆了一长串慢慢就没人看了。后来改成按业务场景归类每类保留固定数量的代表性用例新增必须替换旧的总量控制在可维护范围内。同时给每个用例打上严重等级只有高等级的失败才阻塞发布。这个调整之后评测从跑完就扔变成了真的有人看的环节。第三个坑日志里存了太多敏感信息。为了排查方便早期把完整上下文都落盘了结果日志系统本身成了数据汇聚点。后来做了三件事字段级脱敏、访问日志系统的权限与业务权限对齐、保留周期分级。日志的价值在于能复盘不在于存得全。存得全但不安全等于给自己埋了一个更大的雷。第四个坑把没出事当成没问题。这类系统在低使用量下表现通常很好压力上来之后各种边界情况才暴露出来。我的做法是定期做受控的异常演练故意注入畸形输入、故意让某个工具超时、故意制造权限不足的场景观察系统行为是否可预期。演练的价值在于提前知道失败长什么样而不是等生产环境告诉你。提示把每次演练的结论写进文档而不是留在个人脑子里。这类知识一旦只存在于个别人身上人员变动就会变成系统性风险。最后分享一个我自己坚持了很久的小习惯每次模型、提示词、工具集有任何变更都在变更记录里写一句话——这次变更扩大了哪方面的能力范围。这句话逼着我想清楚变更的实质影响而不是把它当成一次普通的版本迭代。这个习惯成本极低但它让我在多次评审里提前发现了权限与能力不匹配的情况。系统越强边界越需要被显式地写下来这是我做了几年 Agent 之后最实在的一条体会。