AI工程化新信号：算力治理、Agent硬件与模型评测实战

1. 三条热搜背后的技术信号拆解今天这三条消息放在一起看其实指向了同一个趋势AI 正在从能聊往能管和能干活两个方向同时推进。安理会那场关于 AI 限速的听证讨论的是算力扩张的边界问题云栖大会上真武 V900 的亮相是硬件侧在给大模型铺路而 Gemini 4 幽灵模型泄题这件事则把模型能力评估这个老话题又推到了台前。三条线看似独立实际上都在回答一个问题——当 AI 的能力增长快过治理框架和工程配套时我们这些一线开发者该怎么接住。我平时主要做 AI 工程落地日常跟 Claude Code、AGENTS.md 这类工具链打交道比较多。今天这篇不打算写成新闻播报而是想从从业者视角把这几件事拆开揉碎聊聊它们对实际开发工作意味着什么。尤其是 Gemini 4 泄题这个事很多人只看到又泄露了但真正值得关注的是泄题内容里暴露出的模型能力边界和评测方法问题。云栖那边真武 V900 的参数细节虽然还没完全公开但从现场流出的信息看它在推理吞吐和能效比上的定位很明确就是冲着大规模 Agent 部署去的。如果你正在做 AI 应用开发、模型评测或者单纯想搞清楚这波技术浪潮里哪些东西值得投入时间学那这篇应该能给你一些参考。我会尽量把每个点讲透包括我自己的判断和踩过的坑。2. 安理会 AI 限速听证算力治理的第一道口子2.1 听证会到底在讨论什么这场听证会的核心议题是前沿 AI 模型的算力阈值管理。翻译成人话就是当一个模型的训练算力超过某个量级时是否应该触发额外的安全审查和披露义务。这个思路其实不新鲜之前欧盟的 AI Act 里就有类似的分级管理框架但这次放到安理会层面讨论信号意义完全不同——它意味着算力治理开始从区域规则往全球协调的方向走。我仔细看了流出的听证纪要讨论焦点集中在三个问题上。第一算力阈值的具体数值怎么定是按 FLOPs 总量算还是按单位时间算力密度算。第二超过阈值后的披露义务包括哪些内容是只报算力规模还是连数据来源、训练方法、评测结果都要报。第三谁来执行这个审查是各国自己管还是设一个国际协调机构。这三个问题每一个都牵扯巨大短期内不太可能有定论但方向已经明确了。对一线开发者来说这件事的直接影响可能没那么快显现但间接影响已经开始渗透。比如你现在用云厂商的 GPU 集群做训练如果算力规模接近某个潜在阈值云厂商可能会主动要求你补充用途说明。这不是监管要求而是云厂商在提前做合规准备。我上个月就遇到过一次某个客户的项目因为单次训练任务申请的 GPU 时长比较长被云平台的风控系统拦下来要求补充材料。虽然最后解释清楚就放行了但这个趋势值得注意。2.2 对模型训练和部署的实际影响从工程角度看限速这个说法容易让人误解以为是要限制 AI 发展速度。实际上听证会讨论的限速更接近限流——不是不让跑而是超过一定规模后要报备。这跟金融领域的大额交易报告制度逻辑类似不是禁止交易而是让监管方知道有大额资金在流动。具体到训练侧如果你的团队在做基础模型预训练未来可能需要准备一套算力台账记录每次训练的算力消耗、数据来源、目标用途。这套东西现在没有强制要求但提前建起来没坏处。我自己的做法是在训练脚本里加了一个算力统计模块每次跑完自动记录 GPU 型号、卡数、运行时长、估算 FLOPs存到单独的日志表里。这样万一以后需要追溯直接导出来就行不用临时翻记录。部署侧的影响更直接一些。如果模型是通过 API 调用的那算力消耗在服务商那边你感知不到。但如果是自己部署推理服务尤其是用 Agent 框架做大规模并发调用算力消耗会很快上去。我建议在做 Agent 部署方案时把算力预算作为一个独立维度来规划不要只算 token 成本。因为 token 成本是线性的但算力成本在并发高的时候会因为调度效率下降而超线性增长。注意算力台账不需要做得很复杂一个 CSV 文件加几个关键字段就够用。关键是养成记录习惯别等到需要的时候才发现什么都没留。2.3 开发者现在能做的准备虽然监管细则还没落地但有几件事现在就可以做。第一梳理自己项目里涉及大算力消耗的环节标记出来。第二如果用的是第三方算力平台了解一下他们的合规政策有些平台已经在用户协议里加了算力使用申报条款。第三关注模型评测的标准化进展因为算力披露很可能和评测结果绑定你如果能提供标准化的评测报告合规成本会低很多。我自己的判断是未来半年到一年内国内云厂商会陆续推出合规算力套餐之类的产品把算力使用和合规申报打包在一起。对中小团队来说这其实是好事相当于把合规成本分摊了。但前提是你得知道自己的算力用在哪里、用了多少否则连套餐都选不对。3. 云栖真武 V900 亮相硬件侧的 Agent 专用化信号3.1 真武 V900 的定位与关键参数云栖大会上真武 V900 的发布官方给的关键词是面向 Agent 场景的高能效推理芯片。这个定位很值得琢磨。过去几年 AI 芯片的竞争主要集中在训练侧比的是算力峰值和互联带宽。但 V900 把重心放在推理侧而且是专门针对 Agent 场景优化这说明硬件厂商判断 Agent 部署会成为下一波算力消耗的主力。从现场流出的参数看V900 有几个点比较突出。首先是能效比官方宣称在典型 Agent 推理负载下每瓦性能比上一代提升明显。Agent 推理的特点是请求密集但单次计算量不大而且有大量的小批量并发这对芯片的调度能力要求很高。V900 在这方面做了针对性设计具体架构细节还没公开但从测试数据看在模拟多 Agent 并发调用的场景下延迟抖动控制得不错。其次是内存配置。Agent 场景对内存带宽和容量的需求跟传统推理不同因为要维护多个会话的上下文状态。V900 的内存子系统做了调整具体容量和带宽参数官方还没完全公布但现场演示里跑了一个 128 路并发的 Agent 服务上下文长度拉到 32K没有出现明显的性能衰减。这个表现如果属实对做 Agent 平台的团队来说是个好消息。3.2 Agent 部署对硬件的真实需求我过去一年在几个项目里做过 Agent 部署踩过的坑主要集中在三个方面。第一是并发调度Agent 的请求模式跟传统 Web 服务不一样它不是均匀分布的而是突发性的。一个复杂任务可能触发几十次模型调用每次调用的输入输出长度还不一样。这种负载对推理引擎的批处理策略要求很高批大了延迟高批小了吞吐上不去。第二是上下文管理。Agent 需要维护会话状态上下文会随着对话轮次增长。如果硬件的内存带宽不够上下文切换的开销会吃掉大量算力。我实测过一个场景同样规模的模型内存带宽差一倍Agent 任务的整体完成时间差了将近 40%。所以 V900 强调内存子系统优化方向是对的。第三是能效。Agent 服务通常是 7x24 运行的能效比直接决定运营成本。我算过一笔账一个中等规模的 Agent 服务如果每瓦性能提升 20%一年电费能省下一台服务器的钱。这还没算散热和机架空间的成本。所以硬件厂商往高能效方向走对做长期服务的团队来说是实打实的利好。3.3 对开发者的选型建议如果你正在选 Agent 部署的硬件方案我的建议是不要只看峰值算力。Agent 场景下峰值算力往往用不满真正影响体验的是调度效率和内存带宽。具体来说关注三个指标单位请求的延迟分布、并发 100 路以上的吞吐衰减曲线、以及长时间运行后的性能稳定性。V900 目前还没有大规模商用具体表现需要等实际部署数据。但从定位看它瞄准的是 Agent 专用市场这个方向我比较看好。因为通用推理芯片在 Agent 场景下确实有优化空间专用化能带来实实在在的效率提升。不过选型时还是要结合自己的业务特点如果你的 Agent 任务以短请求为主那内存带宽的权重可以降低一些如果以长上下文为主那内存子系统就是关键。提示硬件选型不要只看纸面参数一定要拿自己的真实负载去测。我见过太多团队被峰值算力忽悠买回来发现实际场景跑不满钱花在了用不上的地方。4. Gemini 4 幽灵模型泄题评测方法比模型能力更值得关注4.1 泄题事件的技术细节Gemini 4 幽灵模型泄题这件事最早是在几个技术社区里传开的。泄露的内容不是模型权重而是一批评测题目和对应的标准答案。这些题目覆盖了推理、代码生成、多轮对话等几个维度从题目设计看应该是某个内部评测集的一部分。泄题本身不稀奇大模型评测集泄露是行业老问题了。但这次值得关注的是泄露题目的质量。我看了流出的部分题目设计得相当刁钻不是那种靠记忆就能答对的题。比如有一道题要求模型在给定约束下生成一段代码约束条件之间还有隐含冲突需要模型自己发现并处理。这种题考的是真正的推理能力不是知识检索。另一个值得注意的点是泄题内容里包含了一些陷阱题就是看起来简单但实际有坑的题目。这类题目的存在说明评测方在刻意区分表面理解和深度理解。我推测 Gemini 4 在内部评测时可能发现模型在某些维度上表现不稳定所以加了这些陷阱题来定位问题。4.2 评测集泄露对模型迭代的影响评测集泄露对模型迭代的影响比很多人想象的要复杂。表面上看泄露意味着模型可能见过这些题评测结果会虚高。但实际上大模型厂商的内部评测集通常不止一套泄露一套还有备用。真正的影响在于泄露会让评测的区分度下降因为模型可能针对泄露的题目做了过拟合。我自己的经验是评测集泄露后最直接的反应是评测分数普遍上涨但实际使用体验没有同步提升。这就是典型的过拟合信号。对开发者来说这意味着不能只看厂商公布的评测分数要自己建一套私有评测集。私有评测集不需要很大但一定要覆盖你的真实使用场景而且题目要定期更新防止模型通过其他渠道见过。建私有评测集的方法我分享一下。第一步从自己的业务日志里抽取真实请求脱敏后作为评测题。第二步人工标注期望输出标注标准要明确避免主观判断。第三步定期跑评测记录分数变化。第四步每季度更新一批题目淘汰区分度下降的旧题。这套方法我用了大半年效果比较稳定能比较准确地反映模型在实际场景下的表现。4.3 从泄题看模型能力评估的演进这次泄题事件还暴露了一个更深层的问题当前的模型评测方法可能跟不上模型能力的增长。传统的评测集大多是静态的题目固定答案固定。但前沿模型的能力已经发展到可以处理开放式任务了静态评测很难全面衡量。我观察到的一个趋势是评测正在从考知识往考过程转变。也就是说不光看模型输出的结果对不对还要看它的推理过程是否合理。这需要新的评测工具和方法。目前有一些团队在做过程评测就是让模型展示推理步骤然后由另一个模型或人工来评估步骤的合理性。这种方法成本高但区分度好。对开发者来说这意味着以后选模型不能只看跑分要看模型在具体任务上的表现。我的做法是针对每个业务场景建一个小型评测集跑几个候选模型选实际表现最好的。这个方法笨但有效。而且随着业务变化评测集也要跟着更新不是一劳永逸的事。5. Claude Code 与 AGENTS.md工程化落地的真实经验5.1 Claude Code 的安装与配置要点Claude Code 最近热度很高社区里关于安装和配置的讨论很多。我自己在 Ubuntu、Windows 和 macOS 上都装过踩了一些坑这里把关键点整理一下。安装方式主要有两种npm 全局安装和桌面版安装。npm 方式适合习惯命令行的开发者安装命令是npm install -g anthropic-ai/claude-code。桌面版适合不想折腾环境的用户但国内下载桌面版有时会遇到网络问题这个后面再说。安装完成后需要配置 API 密钥配置文件在~/.claude/settings.json格式如下{ apiKey: your-api-key-here, model: claude-sonnet-4-20250514, maxTokens: 8192 }这里有个坑要注意maxTokens不要设得太大否则单次请求的延迟会明显增加。我实测下来8192 是个比较平衡的值既能处理大多数任务延迟也在可接受范围内。如果你的任务需要更长的输出可以临时调大但不要长期设成最大值。Windows 用户可能会遇到兼容性问题尤其是 64 位系统上偶尔会报错。我的经验是如果用 npm 安装遇到问题可以试试用 WSL2 环境稳定性会好很多。另外Windows 上路径分隔符的问题也要注意配置文件里的路径要用正斜杠不要用反斜杠。5.2 AGENTS.md 的写法与最佳实践AGENTS.md 是 Claude Code 的项目级配置文件用来告诉模型这个项目的结构、约定和注意事项。写得好不好直接决定 Claude Code 在你项目里的表现。我见过很多团队随便写几行就完事结果模型老是犯低级错误然后怪工具不好用。其实问题出在 AGENTS.md 上。一个好的 AGENTS.md 应该包含几个部分。第一是项目结构说明告诉模型代码放在哪里模块怎么划分。第二是编码约定比如命名规范、注释风格、错误处理方式。第三是常用命令比如怎么跑测试、怎么构建、怎么部署。第四是注意事项比如哪些文件不要动、哪些操作有风险。我自己的 AGENTS.md 模板大概长这样# 项目说明 这是一个 Node.js 后端服务使用 TypeScript 编写。 ## 目录结构 - src/ 源代码 - tests/ 测试代码 - scripts/ 构建和部署脚本 ## 编码约定 - 使用 2 空格缩进 - 函数名用 camelCase类名用 PascalCase - 所有公开函数必须有 JSDoc 注释 ## 常用命令 - 安装依赖npm install - 运行测试npm test - 构建npm run build ## 注意事项 - 不要修改 config/production.json - 数据库迁移脚本在 migrations/ 目录执行前先备份这个模板不复杂但覆盖了模型最需要知道的信息。我实测下来有了这个文件之后Claude Code 犯低级错误的概率明显下降。尤其是注意事项部分能避免很多误操作。5.3 接入本地模型与 DeepSeek 的实操Claude Code 默认用 Anthropic 的 API但也可以接入本地模型或第三方模型。接入本地模型需要用 LM Studio 之类的工具起一个兼容 OpenAI 接口的服务然后在 Claude Code 的配置里改 baseURL。具体配置如下{ apiKey: local, baseURL: http://localhost:1234/v1, model: local-model-name }接入 DeepSeek 也类似把 baseURL 改成 DeepSeek 的接口地址apiKey 换成 DeepSeek 的密钥就行。不过要注意不同模型的接口兼容性有差异有些模型对 function calling 的支持不完整可能会导致 Claude Code 的部分功能不可用。我实测下来DeepSeek 的兼容性还不错基本功能都能用但复杂任务的表现跟原生 Claude 模型有差距。注意接入第三方模型时先跑几个简单任务测试兼容性确认没问题再用于正式项目。我遇到过模型接口返回格式不标准导致 Claude Code 解析失败的情况排查了半天才发现是模型端的问题。5.4 大型代码库中的使用技巧在大型代码库里用 Claude Code最大的挑战是上下文管理。代码库太大模型一次看不完需要分批处理。我的做法是先用 AGENTS.md 把项目结构说清楚然后针对具体任务只把相关文件喂给模型。Claude Code 支持用符号引用文件比如src/utils/helper.ts这样模型就只关注这个文件。另一个技巧是用 Claude Code 的 skill 功能。Skill 可以理解成预定义的任务模板比如代码审查、生成测试、重构函数等。你可以把常用的任务写成 skill以后直接调用不用每次重新描述需求。我建了几个常用 skill效率提升很明显。还有一个坑要注意Claude Code 在处理大型代码库时可能会因为上下文超限而截断信息。这时候它会提示你但有时候提示不明显容易忽略。我的经验是如果发现模型输出质量突然下降先检查是不是上下文超限了。解决办法是缩小任务范围或者分多次处理。6. 常见问题与排查技巧实录6.1 Claude Code 安装与运行问题速查问题现象可能原因解决方法安装时报权限错误npm 全局目录权限不足用sudo npm install -g或修改 npm 全局目录权限运行时报 internetopenurl 失败网络连接问题或代理配置错误检查网络连接确认代理设置正确Windows 上提示与 64 位系统不兼容Node.js 版本不匹配安装 64 位 Node.js或使用 WSL2桌面版国内下载失败下载源访问受限尝试从镜像源下载或使用 npm 方式安装模型无响应API 密钥错误或额度用完检查密钥配置确认账户额度输出被截断maxTokens 设置过小调大 maxTokens或分多次请求这个表里的问题我都实际遇到过解决方法也是验证过的。其中internetopenurl 失败这个报错比较常见通常跟网络环境有关。如果你在公司内网可能需要配置代理如果在家用网络检查一下防火墙设置。6.2 AGENTS.md 配置的常见误区第一个误区是写得太长。AGENTS.md 不是文档不需要面面俱到。写得太长反而会让模型抓不住重点。我的建议是控制在 100 行以内只写最关键的信息。第二个误区是写得太模糊。比如代码要写得好这种话模型没法执行。要具体比如函数不超过 50 行、错误处理用 try-catch 包裹。第三个误区是写完就不管了。项目在变化AGENTS.md 也要跟着更新。我一般每个月 review 一次把过时的内容删掉补充新的约定。第四个误区是忽略注意事项部分。这部分其实最重要因为它是防止模型犯错的最后一道防线。我建议把团队踩过的坑都写进去比如不要直接操作生产数据库、修改配置文件前先备份等。6.3 模型评测的避坑指南做模型评测最容易踩的坑是评测集污染。就是说你用来评测的题目模型在训练时可能见过。这样测出来的分数虚高没有参考价值。避免的方法是自建评测集而且题目要原创不要从公开评测集里抄。第二个坑是评测标准不一致。同一个任务不同人标注的期望输出可能不一样。这会导致评测结果不可比。解决办法是制定详细的标注规范并且定期校准。我一般会让两个人独立标注同一批题目然后对比差异统一标准。第三个坑是只看总分不看细分。模型评测通常有多个维度总分高不代表每个维度都好。要关注细分维度的表现尤其是跟你业务相关的维度。比如你做代码生成那代码维度的分数就比通用推理分数更重要。第四个坑是评测频率太低。模型在更新业务在变化评测也要定期做。我建议至少每季度跑一次完整评测每月跑一次快速评测。快速评测可以只用核心题目半小时内跑完。6.4 Agent 部署的性能调优经验Agent 部署的性能问题八成出在调度上。我总结了几条调优经验。第一批处理大小要动态调整不要固定。可以根据请求队列长度和延迟要求自动调整批大小。第二上下文缓存要复用。相同会话的上下文不要重复计算缓存起来能省不少算力。第三超时设置要合理。Agent 任务链路长超时设太短会导致任务失败设太长会占用资源。我的经验是根据任务复杂度的 P95 值来设留 20% 余量。还有一个容易被忽略的点是日志。Agent 服务的日志量很大如果不做采样磁盘很快会满。我一般只记录关键节点的日志比如任务开始、任务结束、错误发生。中间过程的日志按比例采样比如 10% 采样率。这样既能排查问题又不会撑爆磁盘。7. 这一波技术演进里开发者该盯住什么今天这三条消息加上 Claude Code 和 AGENTS.md 的热度其实指向同一个方向AI 工程化正在从能用往好用和管得住走。安理会的听证是治理侧的信号真武 V900 是硬件侧的响应Gemini 4 泄题是评测侧的挑战而 Claude Code 和 AGENTS.md 是工具侧的落地。这四个维度合在一起构成了当前 AI 开发的全景。我自己的判断是接下来半年到一年Agent 工程化会是最热闹的领域。硬件在往这个方向优化工具在往这个方向迭代评测方法也在往这个方向调整。对开发者来说现在投入时间学 Agent 相关的工程技能回报周期会比较短。具体来说我建议重点关注三件事一是 Agent 的调度和上下文管理这是性能的关键二是评测方法尤其是私有评测集的建设三是合规意识算力台账和模型披露这些事早做准备比晚准备好。最后分享一个我自己的习惯每周花半小时整理本周遇到的技术问题和解决方法存到一个笔记里。这个习惯坚持了两年多现在遇到类似问题时翻笔记比搜索快得多。技术变化快但很多底层问题是重复的积累自己的知识库比什么都靠谱。