当 Demis Hassabis 站到 Google 更全局的位置时科技圈关注的不只是个人职级变化而是前沿 AI 研究与产品商业化之间的平衡。这种平衡行为并不只发生在巨头公司里。任何要把 AI 功能落到生产环境的开发团队都会面对类似的选择题模型选多大成本能承受多少是追最新研究还是保稳定可用Agent 要开放多少能力才不会失控。下面这些内容围绕 AI 工程实践中最容易被忽视的几层平衡展开。这篇文章不打算评论公司人事而是把“AI 平衡行为”翻译成工程问题。你会看到模型选型、Agent 开发、AI 幻觉治理、部署运维和排错链路中哪些决策决定了项目是停留在 Demo还是能真正支撑业务。1. 大公司组织架构调整背后是 AI 工程的三大张力1.1 为什么“研究与产品”的平衡会成为焦点DeepMind 与 Google AI 的整合在行业讨论中一直是一个高频话题。观点文章喜欢用“Hassabis 的新角色”作为引子说明一个核心矛盾一个以顶会论文和前沿探索为基因的研究团队如何与一个以发布节奏、用户增长和收入为目标的商业产品部门协同。这种讨论之所以成立是因为两边的工作评价体系完全不同。研究团队追求的是上限是“模型能不能做到以前做不到的事”产品团队追求的是下限是“功能在千万用户访问时会不会崩、回答会不会出错、延迟能不能接受”。当一个人同时对两边负责所有冲突都会集中到决策层。如果你在大厂或创业公司做过 AI 项目会发现这不是公司政治而是工程现实。研发说“换更大的模型效果更好”运维说“当前 GPU 资源扛不住并发”产品说“用户等不了 5 秒”测试说“这次回答又和上次不一样”。所有声音都是对的但必须有人做取舍。1.2 从组织平衡到工程平衡三组矛盾把组织层面的讨论往下拆会得到三组在代码和配置里真实存在的矛盾。矛盾研究/前沿导向产品/工程导向典型表现能力选择追求最新模型、最大参数量追求可复现、可维护的稳定输出模型版本频繁更换测试集反复失效资源成本为了上限可以接受高成本单位请求成本必须可控Token 消耗失控账单暴涨安全约束希望模型能力完全释放必须限制输出范围和权限Agent 工具调用越权内容不合规这三组矛盾不是理论。模型选型时要遇到Agent 设计时要遇到内容审核和权限控制时还要遇到。理解它们等于理解了 AI 工程化的大框架。1.3 普通开发者的“平衡行为”在哪里小团队没有大公司的组织问题但技术决策上一样要平衡。比如调用一个能力很强的闭源 API还是部署一个可控但效果稍弱的开源模型。让 Agent 自动执行工具还是每次执行前都人工确认。给模型完整的上下文窗口还是用 RAG 只塞相关片段。追求零人工干预还是保留一个兜底审核环节。这些决定看似琐碎却决定了系统是“演示时惊艳”还是“上线后稳定”。后面的内容会按一条主线把这些决策串起来模型选择、Agent 开发、幻觉治理、部署运维、排查修复。2. 模型选择先想清楚你要的是“研究成果”还是“生产可用”2.1 模型选型三件套效果、成本、延迟很多团队选模型只看 benchmark 分数这是第一个坑。生产环境里效果只是三个约束之一。真正要同时看的是效果在你自己业务数据上的表现而不是公开榜单上的分数。成本单次请求的 Token 消耗、调用费用长期跑下来是否可承受。延迟P50 和 P95 响应时间用户可感知的等待时间。三者的关系通常是这样模型越大效果越好但成本和延迟也越高。你能做的是找一个“够用”的平衡点而不是“最强”的模型。选型维度关注点常用评估方式错误做法效果业务场景准确性、格式遵循自建评测集跑回归对比只看公开榜单成本单次请求费用、月账单压测平均 Token 数估算规模上线前不测算延迟用户等待时间、并发吞吐P50/P95 压测长尾分析只测一次单请求一个更常见的场景是同一套业务读操作和写操作用不同模型。例如标题生成、摘要提取这类简单任务用轻量模型复杂推理或代码生成用更强模型。这比把所有流量都打到最大模型上更省钱也更容易控制延迟。2.2 开源自建和托管 API 的取舍“要不要自己部署模型”是一个经常被问错的问题。正确的问法是你的团队有没有能力维护推理服务。托管 API 的好处是省心不用管 GPU、扩容、模型文件代价是数据要出域成本按调用量累积而且模型行为可能随版本变化。开源模型自建的好处是数据可控、单次调用边际成本低代价是硬件投入大推理性能调优需要专门能力版本升级和兼容性也要自己维护。对比项托管 API自建开源模型部署门槛低几行代码调用高需要推理服务和 GPU 资源数据隐私取决于服务条款数据留在自己环境单位成本按 Token/请求计费主要是硬件和电费量大时更省模型可控性依赖服务方版本策略可以固定版本、自己微调运维成本几乎为零监控、扩容、日志、回滚都要做这里的建议是初创项目、快速验证阶段优先用托管 API当调用量稳定、数据合规要求变高时再把高频路径切到自建模型。不要一开始就把精力耗在部署上。2.3 用接口抽象隔离模型变化无论选哪种模型代码里都不要直接写死某个厂商的 SDK。下面是一个最小抽象示例用统一接口封装不同 Provider后续换模型时只需要新增实现。from dataclasses import dataclass dataclass class ModelConfig: provider: str model_name: str max_tokens: int 1024 temperature: float 0.1 class LLMClient: def __init__(self, config: ModelConfig): self.config config def chat(self, messages: list[dict]) - str: if self.config.provider openai_compatible: return self._call_openai_compatible(messages) if self.config.provider local: return self._call_local(messages) if self.config.provider custom: return self._call_custom(messages) raise ValueError(funknown provider: {self.config.provider}) def _call_openai_compatible(self, messages): # 这里放 OpenAI 兼容接口的调用逻辑 pass def _call_local(self, messages): # 这里放本地推理服务的调用逻辑 pass def _call_custom(self, messages): # 这里放内部中转服务的调用逻辑 pass关键不是实现多少 Provider而是把“业务代码”和“模型供应商”解耦。模型升级、替换、迁移时业务侧不需要改逻辑只改配置和新增适配层。这会成为后期做灰度发布和多模型容灾的基础。3. Agent 开发的核心不是“让模型多聪明”而是“给模型多少权限”3.1 Agent 为什么成为 AI 应用的标配单个模型只能回答Agent 可以做事情。它的价值在于把模型的语言理解能力与工具、API、数据库、业务流程连接起来。比如用户说“帮我查一下最近的订单状态”Agent 先判断要调用订单查询工具再提取参数拿到结果后组织成自然语言回答。这也是“AI Agent 开发”在工程实践里越来越重要的原因。但 Agent 带来的不仅仅是能力提升还引入了一个新的风险面模型在决定调用什么工具、传什么参数一旦权限边界没设好可能执行出开发者没有预期的操作。3.2 最小工具调用闭环Tool Call 的整个链路一个最小 Agent 必须完成五步识别意图、生成工具调用参数、执行工具、把结果送回模型、生成最终回答。下面是一个简化示例模拟天气查询。import json def get_weather(city: str) - str: # 实际项目里应该调用真实天气服务 return f{city} 当前晴天气温 26 度 TOOL_SCHEMA { type: function, function: { name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: { type: string, description: 城市名例如 北京 } }, required: [city] } } } def run_agent(query: str, llm_client) - str: messages [ {role: system, content: 你是天气助手。根据用户问题决定是否调用工具。}, {role: user, content: query} ] response llm_client.chat_with_tools(messages, tools[TOOL_SCHEMA]) if response.tool_calls: call response.tool_calls[0] args json.loads(call.function.arguments) # 执行工具 tool_result get_weather(args[city]) # 把工具结果追加到对话再让模型总结 messages.append(response.message) messages.append({ role: tool, tool_call_id: call.id, content: tool_result }) final_response llm_client.chat(messages) return final_response.content return response.content这个流程里有三个容易出问题的地方一是模型输出的 tool call 参数可能不是合法 JSON二是工具执行可能抛异常三是工具结果返回后模型可能仍然回答错误。工程化时这三步都要加异常处理和校验。3.3 Agent 权限边界和失败兜底Agent 越强大越需要约束。一个只读天气工具和一个能操作数据库、发送邮件、执行命令的工具风险等级完全不同。不要把所有工具一股脑暴露给模型。Agent 风险典型场景缓解手段工具越权模型调用了无权限接口工具注册表上做权限标记服务端校验参数注入用户通过提示词诱导改变工具参数对工具参数做类型、范围、枚举校验误操作连续调用多个副作用工具高风险工具增加二次确认或人工审批供应链工具返回的数据被恶意构造对工具返回内容做序列化校验和长度限制建议早期把 Agent 设计成“建议式”模型只给出应该调用哪个工具和参数真正执行前由人工或固定规则确认。等线上跑稳了再逐步放开自动执行同时保留完整审计日志和紧急熔断开关。4. AI 幻觉和内容合规是同一个问题的两面4.1 AI 幻觉是什么为什么只靠提示词压不住AI 幻觉是指模型生成的内容看起来合理但事实错误、无中生有。常见原因包括训练数据不完整、上下文信息不足、模型为了“自洽”会补全不存在的细节。很多人试图通过提示词压制幻觉比如在 system prompt 里写“不要编造事实”。这在简单场景里有效但在复杂任务中并不可靠。因为模型本质上是概率生成没有真正区分“知道”和“不知道”的能力。提示词可以改变输出风格但不能确保事实正确。工程上控制幻觉要从外部约束和验证入手。4.2 用 RAG 和事实校验约束输出RAG检索增强生成是目前最实用的手段先检索相关资料再让模型基于资料生成。它不要求模型记住所有知识只要求它理解给定资料。def verify_with_source(answer: str, source_docs: list[str]) - bool: sources_text \n.join([f[{i1}] {doc} for i, doc in enumerate(source_docs)]) prompt f请判断下面的回答是否完全基于给定资料。 如果回答中的关键结论都能在资料中找到依据输出 PASS。 如果回答中包含资料里没有的事实或推测输出 FAIL。 资料 {sources_text} 回答 {answer} 判断结果 result judge_llm.predict(prompt) return result.strip().upper() PASS这里的校验模型可以用一个更便宜的模型不一定和生成模型同一个。流程上先生成回答再校验校验不通过就换一种方式回答比如“资料中没有找到相关信息”。成本会增加一些但换来的确定性是值得的。4.3 面向用户的内容审核要当作安全组件任何面向用户的内容都不应该只依赖模型本身。你的产品可能有自己的内容规范模型并不天然知道你允许什么、禁止什么。工程上通常做三层过滤输入侧过滤对用户输入做长度、类型、关键词、格式校验。输出侧过滤对模型输出做关键词、分类模型、审核 API 检测。人工兜底高风险场景保留人工复核或举报入口。审核模块要像日志和监控一样作为基础设施接入而不是后补。它应该返回结构化结果是否通过、命中的规则、风险类型、触发位置这样后续排查和迭代才有数据支撑。5. 从 Demo 到生产模型部署和可观测性5.1 学习环境和生产环境的差异很多 AI 项目死在“本地能跑”到“线上稳定”之间。本地 Notebook 调试和生产环境部署是完全两套思路。维度学习/开发环境生产环境模型文件放在本地目录镜像化、版本化管理依赖本机 conda/pip锁定版本可重复构建并发单用户调试压测后配置自动扩缩容日志print 输出结构化日志、链路追踪故障重启即可需要监控、告警、回滚成本不关注按次计费、资源配额生产环境至少要补上三件事配置外置化模型地址、API Key、参数不写死在代码里、健康检查接口、优雅退出机制。5.2 一个最小容器化部署示例无论模型是部署在本机还是通过 API 调用业务服务先容器化是可行的第一步。下面是一个最小 Dockerfile用于打包一个 FastAPI 推理服务。FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . ENV MODEL_CACHE_DIR/models ENV API_TIMEOUT30 EXPOSE 8000 CMD [uvicorn, app.main:app, --host, 0.0.0.0, --port, 8000]这里的关键点是ENV MODEL_CACHE_DIR和API_TIMEOUT不应该在构建时写死而是在启动容器时注入。这样不同环境测试、预发、生产可以复用同一个镜像只改环境变量。模型文件如果很大建议挂载外部存储而不是打进镜像。5.3 日志、监控、回滚和成本治理上线后最该看的是三个面板模型调用量、错误率、Token 消耗。尤其 Token 消耗这是 AI 应用最容易失控的成本项。指标建议监控粒度异常信号平均 Token/请求按天、按功能某个功能突然翻倍错误率按分钟、按状态码4xx/5xx 突增延迟 P95按小时持续走高说明并发瓶颈内容审核命中率按天输出侧风险明显上升模型版本占比按天灰度流量和回滚观察回滚策略同样重要。模型升级不像普通代码行为变化往往是非预期的。上线前要把旧模型保留一段时间新模型使用小流量灰度出现质量下降或成本异常时能迅速切回旧版本。6. AI 工程实践的高频坑与排查链路6.1 三个高频坑第一个坑输出不稳定。现象是同样的输入每次回答都不一样测试用例时好时坏。常见原因是temperature设置过高或者没有用seed等采样参数。解决办法是按场景区分参数分类、抽取任务用低温度创意生成任务才调高温度。第二个坑上下文超限。现象是请求报错提示context length exceeded或者长对话越来越慢。常见原因是把整段历史全部塞给模型。解决办法是做上下文裁剪、摘要压缩或者改用 RAG 只放相关片段。第三个坑Tool Call 解析失败。现象是模型返回的工具调用参数不是合法 JSON或者参数类型不符合预期。常见原因是直接信任模型输出。解决办法是在解析时做容错例如用流式解析、补充说明、重试一次同时给工具参数做严格校验。6.2 从现象到根因的排查顺序AI 系统排查和传统系统不太一样建议按下面顺序查输入是否正确消息格式、角色字段、上下文长度是否符合模型要求。配置是否生效temperature、max_tokens、top_p 是否被代码覆盖。模型是否选对当前模型是否适合这个任务是否被系统自动降级到了弱模型。提示词是否稳定同一提示词在不同模型版本下行为差异是否明显。工具链路是否正常工具有没有抛异常、返回内容有没有被截断。审核或过滤层是否误杀输出是否被规则拦截但开发环境没有相同规则。资源水位是否健康延迟变高、超时增多时检查 GPU 利用率、连接池和限流。6.3 排查清单问题现象可能原因检查方式处理建议回答前后不一致采样参数不合理固定 seed、降低 temperature按场景调整参数长文本报错上下文超限查看请求上下文 token 数截断、压缩、RAG工具调用失败模型输出非法参数打印原始 tool_call 内容加 JSON 容错和重试偶发超时并发或慢查询看 P95 延迟和连接池增加超时控制和限流审核误拦截规则过粗查看审核命中的规则明细细化规则和放行逻辑成本突增请求量或 Token 膨胀按功能维度拆分 Token 报表设置预算告警和配额这份清单可以贴在项目文档里每次线上问题按照它过一遍能省去很多猜测时间。7. 把“平衡”落地成工程规范7.1 项目启动前写清目标研究 Demo 还是线上功能给团队定一个方向比写代码更重要。项目初期先回答四件事这是内部验证还是要长期运维的外部功能。允许的最大单次调用成本和月成本是多少。回答错误会造成什么影响需要多高的兜底级别。模型升级时是接受行为变化还是必须固定版本。目标不同后面的技术决策会完全不同。研究 Demo 可以用最新模型、不做监控线上功能则要求稳定、可回滚、可观测。7.2 定义“不做什么”和“人工兜底”边界AI 工程最常见的错误是过度承诺。面对需求时最好明确哪些场景 AI 不做、哪些场景 AI 只做辅助、哪些场景必须人工复核。给模型画边界不是限制能力而是让能力落在可控范围内。7.3 可落地的工程规范从接口抽象到分级发布建议把下面的规范写进团队文档所有模型调用走统一接口层禁止业务代码直接拼接供应商 SDK。所有在线调用必须有超时、重试和熔断。所有高风险操作在 Agent 工具层做权限校验。所有模型输出先过审核层再返回用户。所有模型版本变更走灰度发布预留回滚通道。所有 Token 消耗按功能维度记录便于成本分析。这些规范不复杂但能在关键时候救项目一命。7.4 给新手的下一步如果你刚接触 AI 工程不要一上来就追求“全自动化 Agent”或“大规模自部署”。建议按这个顺序练习先调通一个模型 API封装统一调用接口再加一个工具调用理解 Tool Call 链路然后接数据库或搜索做一次 RAG 应用最后补上监控、审核和回滚。每一步都跑通再进入下一步。AI 应用开发和传统软件开发最大的区别是系统的行为不再完全由代码决定模型本身会带来不确定性。所以工程的本质不是消除不确定性而是设计一套机制在不确定性存在的前提下依然让系统稳定、可靠、可解释。这也是 Google、DeepMind 那些大组织在讨论的平衡最终落到每个开发者代码里的样子。