企业官网建设流程全解析

最近，技术圈被一条关于 DeepMind 核心人物考虑离职的传闻刷屏。消息本身并没有得到官方证实，信源也比较模糊，但几乎所有人讨论时都默认了一个前提：如果 DeepMind 的关键灵魂人物真的离开，谷歌在 AGI 竞赛中的节奏一定会被打乱，甚至整个研究路线的推进都会受到影响。

一条未经证实的传闻能引发这么大的讨论，本身就说明了一个问题：在 AI 行业，顶尖人才比任何单一模型、任何一座超算中心都稀缺。过去我们习惯把谷歌、DeepMind 想象成一座不可撼动的 AI 堡垒，觉得它有顶级大脑、无限算力、宽松的研究氛围，人才不可能流失。但现实显然不是这样。这背后的信号值得每一个技术人认真解读。

所以这篇文章不打算继续吃瓜，也不想去猜测某个人的去向。我更想聊的是三件事：第一，谷歌和 DeepMind 这样的顶级 AI 组织，为什么也会面临人才危机；第二，AGI 研究与商业公司之间的结构性矛盾，到底出在哪里；第三，作为普通开发者，我们能从这类事件中提炼出哪些真正可用的技术判断和职业策略。

1. 为什么一条没有实锤的传闻，能引爆技术社区

先还原一下背景。DeepMind 是全球 AI 研究领域公认的顶级团队，2010 年成立，2014 年被谷歌收购，后来并入谷歌 AI 体系。这家公司做出过 AlphaGo、AlphaFold、AlphaProof、AlphaGeometry 等一系列标志性成果，在强化学习、蛋白质结构预测、数学推理、博弈智能等方向长期保持领先。如果说 OpenAI 是产品化、工程化路线上的代表，那么 DeepMind 更像是基础研究和长期探索路线的代表。

正因为地位特殊，任何一点人才震动都会被放大。近期社区讨论中有一种声音认为，连 DeepMind 的创始核心都可能对谷歌的管理方式感到不满，正在考虑其他选择。这个消息没有官方背书，也无法核实，但它在技术社区传播得非常快。大家关心的其实不是某个具体人物的个人选择，而是一个更宏大的问题：如果连 DeepMind 这样的组织都留不住核心人才，AI 研究领域的人才竞争到底已经激烈到什么程度了？

这里有一个更值得注意的观察点。过去几年，AI 头部公司之间的竞争已经不只是模型参数的竞争，而是人才、算力、数据、工程体系、组织文化的全方位竞争。算力可以花钱买，数据可以积累，工程体系可以慢慢建设，唯独顶尖人才的去留最难控制。一个人离开，可能意味着一个研究方向停摆，一群核心成员的跟随，甚至一套研究范式的转移。这正是谷歌真正怕的地方：它不怕某个产品的失败，怕的是 DeepMind 这套已经验证过的研究范式被带到竞争对手那里去。

从技术组织的管理角度看，这个担忧是有依据的。顶尖 AI 研究者的产出高度个人化，一个团队里贡献最大的那几个人，可能贡献了绝大部分的突破性成果。这些人拥有极强的学术声誉、行业影响力和创业号召力，一旦他们走出去，拉团队、找算力、拿融资都相当容易。对于商业公司来说，这种结构性风险是长期存在的，只能通过更强的绑定机制、更灵活的激励方式和更宽松的研究环境去缓解。但现实是，大公司有合规要求、有产品周期、有成本控制，这些和顶尖研究者的诉求天然存在摩擦。

所以，这条传闻之所以能刷屏，不是因为八卦本身有多精彩，而是因为它精准踩中了整个 AI 行业最敏感的一根神经：人才。技术人看到的是人才争夺，管理者看到的是组织风险，投资者看到的是路线变化。这种多层次的解读空间，让一条未经证实的消息具备了极高的传播价值。

2. DeepMind 的特殊性：它不只是一家公司，而是一种研究范式

要理解谷歌为什么对 DeepMind 人才流失这么敏感，必须先理解 DeepMind 在 AI 版图中的独特位置。和大多数 AI 公司做产品、做应用、做商业化模型不同，DeepMind 的自我定位是“解决智能问题”。它的招牌方向是 AGI——通用人工智能，也就是让机器具备跨任务、跨领域的通用学习和推理能力，而不是只能做某一项具体任务。

这种定位带来两个显著特点。

第一，研究周期极长。AlphaGo 从立项到击败李世石经历了多年积累，AlphaFold 从早期版本到解决蛋白质结构预测问题也走过了漫长的道路。AGI 方向的成果往往无法按季度衡量，更无法像互联网产品那样快速发布、快速迭代。商业公司习惯于设定 OKR、季度复盘、年度考核，但真正的 AGI 研究很难用这些标准来评价。你没法说“这个季度我完成了通用智能的 8%”，研究进度是非线性的。

第二，研究方法强调跨学科融合。DeepMind 的团队构成不只是机器学习工程师，还包括神经科学、认知科学、数学、物理、计算生物学等背景的研究者。这种跨学科组合让 DeepMind 在算法设计上有独特的视野，比如 AlphaGo 里的价值网络和策略网络设计，就明显受到人类棋手“直觉判断”和“深度思考”两种模式的启发。这种组织形态和大厂普遍的产品研发团队差异非常大。

用工程来类比可能更容易理解。AGI 研究更像基础科学而不是应用开发。基础科学的价值不能完全用商业回报来衡量，但它决定了未来十年的技术上限。谷歌当年收购 DeepMind，本质上是在为十年甚至二十年后的技术霸权下注。如果 DeepMind 的核心人才流失，谷歌失去的不仅仅是几个项目，而是通往下一代智能形态的探路能力。

那么，DeepMind 内部面临的真正问题是什么？从公开信息和技术社区讨论来看，矛盾主要集中在几个方面：研究自由和商业目标之间的平衡、大组织决策链路变长、内部资源分配越来越偏向短期产品需求，以及人才晋升和激励体系对大牛们的吸引力下降。这些问题在几乎所有大型 AI 组织中都会出现，只是 DeepMind 因为研究方向太前沿、人才太集中，表现得尤为明显。

从技术角度看，还有一个隐性问题是研究方法的分化。DeepMind 擅长的是强化学习和环境交互范式，而过去几年大模型行业的主流是“扩展定律”驱动的大规模预训练。后者强调算力堆叠、数据规模和参数规模的指数级膨胀，而前者强调算法结构、奖励设计和智能体与环境的交互。当一家公司把更多资源投入到与 OpenAI 直接对标的竞品上时，原本以长期探索为主的团队就会出现方向焦虑。这种路线之争，可能比单纯的管理矛盾更有杀伤力。

3. AI 顶尖人才为什么总是留不住：五个结构性原因

很多人看到顶级 AI 人才离职新闻，第一反应是“为什么给那么多钱还不够”。实际上，顶尖 AI 研究者的离职逻辑和普通打工人完全不一样。钱只是必要条件，不是充分条件。真正推动他们离开的，往往是以下几种结构性因素。

第一个因素是研究人员的价值高度个人化。在 AI 领域，一个优秀的算法研究员对项目的贡献可能是普通工程师的几十倍甚至上百倍。一个核心研究者离开，可以直接带走一个方向的技术路线图。这种高度的个人可迁移性，让顶尖研究者拥有了极高的议价能力。他们不需要依赖大厂平台才能做出成果，反而经常是平台依赖他们来保持技术领先。

第二个因素是 AGI 创业窗口正在快速打开。过去十年，顶级 AI 研究者离开大厂创业要冒很大风险，因为算力成本和数据获取都是门槛。但最近两年，AI 基础设施越来越完善，开源模型、云算力、融资环境都变得更友好。一个顶级研究者带着几个核心成员，完全可能搭建出一个足以挑战大厂的团队。更重要的一点是，创业之后可以获得更大的研究自由，不用再应付复杂的大厂流程，这对顶尖研究者来说是非常强的吸引力。

第三个因素是大厂考核体系与 AI 研究长期性之间的冲突。大公司总说要给研究者空间，但实际运行时，预算审批、项目评审、KPI 定义都会慢慢向短期可交付成果倾斜。一个需要五年才能看到结果的研究方向，在商业公司内部是很难持续拿到最高优先级的。即便 DeepMind 这种已经获得相对独立性的组织，也难以完全脱离谷歌整体的商业考量。这种长期主义和短期主义的对抗，是研究型组织永恒的难题。

第四个因素是算力资源配置的内部博弈。大模型时代的竞争，本质上是算力竞争的一部分。模型训练、评测、迭代都依赖大规模算力支持。在组织内部，研究项目需要在算力分配上和产品项目PK。产品项目有明确的商业回报预期，容易获得预算；前沿研究项目则经常处于“重要但不紧急”的位置。如果顶尖研究者觉得自己的算力需求得不到满足，他们很容易产生“不如自己拉一支团队、直接购买云算力”的想法。

第五个因素是控制权和声誉归属问题。研究者非常看重自己工作的可识别性和成果归属感。AGI 领域的研究者目标往往是成为下一个图灵奖得主，或者建立自己的研究学派。在大厂内部，很多研究成果会以团队名义发布，个人辨识度被稀释。这也是为什么很多顶级研究者出去创业时，强调“我要建立属于自己的实验室”。控制权带来的不只是经济利益，更是长期研究方向的把握能力。

这些因素叠加在一起，形成了一个明显的趋势：AI 顶尖人才的忠诚度，已经从“组织忠诚”转向“方向忠诚”和“自我实现”。他们忠诚的是自己的研究路线，而不是某家公司的工牌。大厂想留住他们，不能只靠高薪和股权，而是必须创造一个让他们觉得“在这里能比在外面更快接近 AGI”的环境。这种要求，对任何商业组织来说都是极高的挑战。

4. 从研究到产品：AI 组织真正缺的是工程化能力

DeepMind 的模型能力一直是行业顶尖的，但模型能力强并不意味着产品就能顺利落地。实验室里的 SOTA 模型和线上稳定运行的产品系统之间，隔着一条非常宽的工程鸿沟。过去几年，这个认知已经被反复验证：很多研究成果非常漂亮的团队，在做产品化时表现得并不理想，反而是工程化能力强的团队更容易把模型变成用户可用的服务。

这条鸿沟体现在哪里？

首先是数据管道。实验室常用的是经过清洗、筛选、配比优化的公开数据集，而真实业务数据是脏的、不均衡的、实时变化的，需要在采集、清洗、标注、版本管理、质量监控上投入大量工程力量。其次是训练稳定性。论文里的训练实验通常是单次或几次跑通，但产品级模型需要可复现、可回滚、可监控的训练流程。第三是评测体系。研究论文里的评测指标通常是学术基准，比如 GLUE、MMLU，但真实产品需要针对业务场景定制评测集，持续监控模型上线后的效果漂移。

还有一个容易被忽略的环节是模型服务化。模型训练完之后，要解决延迟、吞吐、成本、并发、容灾等一系列问题，才能支撑线上流量。和传统后端服务相比，大模型推理的资源消耗更大，弹性扩缩容的粒度不同，优化手段也不同。这需要专门的推理优化团队，而不是算法团队顺手可以做好的事。

更关键的是安全护栏。研究环境里，模型输出跑偏了可以重新跑一次；生产环境里，一次错误输出可能造成严重的用户体验问题，甚至带来合规风险。所以产品级 AI 系统必须做输入过滤、输出过滤、内容安全检测、敏感信息脱敏、人工审核兜底等多层防护。这些工作不会出现在论文里，但决定了 AI 能否真正落地。

如果 DeepMind 这类研究型团队在工程转化上有短板，那么谷歌在产品化过程中就会面临一个经典矛盾：研究团队希望模型更聪明、能力更强，工程团队希望模型更稳定、成本更低、更可控。两个团队的目标函数不一致，资源竞争和决策冲突就会出现。而人才流动，往往是这种深层矛盾的表面结果。

对普通开发者来说，这里有一个非常重要的启示：AI 行业缺的不只是“会训练模型的研究员”，更缺“能把模型变成可靠系统”的工程师。今天你或许不需要做前沿算法研究，但如果你能把模型调用、评测、调优、部署、监控、安全这一整套工程链路跑通，你在团队中的价值会非常高。这类人才，才是 AI 组织从研究走向产品过程中真正稀缺的资源。

5. 普通开发者应该从这场风波中带走什么

回到现实。DeepMind 核心人才是否真的离开，我们无法确认，也不应该把一个未经证实的传闻当成事实来理解。但这场风波背后反映出的行业趋势，确实值得每一个技术人认真思考。哪怕我们不在一线大厂，不做 AGI 研究，这些趋势也会在未来的职业选择中影响到我们。

第一句话：不要在技术阵营上押注。很多开发者会习惯性地站队，比如“谷歌系一定更强”“OpenAI 一定更有前途”。但从行业底层逻辑看，技术路线会迭代，组织会变化，甚至今天的头部公司也可能在五年后失去优势。真正值得押注的，是那些跨越具体平台的能力：对大模型原理的理解、对评测方法的掌握、对 Agent 架构的判断、对 AI 安全边界的认知。这些能力不会因为某家公司人事变动而贬值。

第二个判断：模型能力正在快速商品化，工程能力才是护城河。今天，主流大模型之间的能力差距在快速缩小。一个应用如果只是简单调用某个模型 API，那么它没有任何壁垒，因为别人可以很快用同一个 API 做出同质化产品。真正的差异化来自工程侧：你如何筛选模型，如何构造评测集，如何设计 RAG 流程，如何保证 Agent 输出稳定可控，如何用最低成本达到最好的业务效果。这些综合起来，决定了产品在真实用户面前的表现。

第三点：注意“模型跑分”和“真实可用”之间的差距。大模型评测榜单上的分数提升，并不等于实际业务效果的提升。很多开发者只看 MMLU、HumanEval 等公开基准，却忽略了模型的鲁棒性、偏见、幻觉和安全性。在真实场景中，真正决定用户满意度的，往往不是模型的知识量，而是它在边界情况下的表现。这就引出了一个更重要的能力：要学会搭建自己的评测体系，而不是完全相信第三方榜单。

从学习路径上看，普通开发者可以按这样的顺序建立能力。第一阶段是模型调用和 Prompt 工程，掌握 API 的基本用法和上下文设计技巧。第二阶段是评测体系建设，学会用一组覆盖正常、边界、对抗场景的测试用例来衡量模型效果。第三阶段是 RAG 应用，把模型和外部知识库结合，解决幻觉问题和知识时效问题。第四阶段是 Agent 工作流开发，让模型学会调用工具、执行多步任务。第五阶段是系统化工程，解决部署、监控、安全、成本等生产环境问题。

这五个阶段的核心，不是某一个模型的 API，而是一套可以迁移的 AI 工程思维。不管谷歌 DeepMind 发生了什么，这五个方向的价值只会越来越强。

6. 动手实践：搭建一个简单的模型评测工作台

前面说了评测体系很重要，很多人会问：到底怎么搭？这里给出一个最小可用的模型评测工作台方案。它的目标不是构建完美的评测平台，而是让你用几十行代码跑通“定义评测题目 → 调用模型 → 收集结果 → 规则打分”的完整流程。

思路是先准备好一个评测脚本，批量向模型 API 发送问题，然后把回答保存成 JSON 文件，再用一个评分脚本对回答做规则匹配。规则评分虽然简单，但足够作为一个起步版本。后期你可以把规则打分替换为更强模型的裁判打分，也可以加入人工审核环节。

先看模型调用和结果收集脚本。假设你使用的是支持 OpenAI 兼容接口的模型服务，可以是云厂商的模型网关，也可以是自部署的推理服务。代码中使用的是一个占位 endpoint 和占位密钥，实际使用时要替换成你自己的配置。

# evaluate_models.py import openai import json import time client = openai.OpenAI( api_key="your-api-key", base_url="https://your-model-endpoint" ) models = ["model-a", "model-b"] eval_cases = [ {"category": "基础概念", "prompt": "请用一句话解释什么是强化学习。"}, {"category": "代码能力", "prompt": "写一个 Python 函数，判断一个字符串是否是回文。"}, {"category": "逻辑推理", "prompt": "如果所有 A 都是 B，有些 B 是 C，可以推出有些 A 是 C 吗？请说明理由。"}, ] def run_model(model, prompt): resp = client.chat.completions.create( model=model, messages=[ {"role": "system", "content": "你是一个严谨的技术助手，回答要准确、简洁。"}, {"role": "user", "content": prompt} ], temperature=0.2, ) return resp.choices[0].message.content results = {} for model in models: results[model] = [] for case in eval_cases: output = run_model(model, case["prompt"]) results[model].append({ "category": case["category"], "prompt": case["prompt"], "output": output, }) print(f"[{model}] 评测完成: {case['category']}") time.sleep(1) with open("eval_results.json", "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) print("评测完成，结果已保存到 eval_results.json")

这段代码有几个关键细节需要解释。

第一，temperature 设置为 0.2，目的是让模型输出更稳定。评测场景下，我们想衡量的是模型的知识和能力，而不是它的创造力。如果 temperature 过高，同一条题目同一个模型两次回答可能差异很大，评测结果就不具备可重复性。

第二，system prompt 对结果影响很大。这里要求模型“严谨、准确、简洁”，等于给模型设定了一个输出框架。实际做评测时，不要忽略 system prompt 的作用，只要有可能，所有候选模型都应该用相同的 system prompt，否则结果不具备可比性。

第三，请求之间加 sleep(1)，是为了避免并发请求触发限流。如果你需要评测的模型多、题目多，建议做成异步并发，并做好重试和日志记录。这里的最小示例不追求吞吐，只追求跑通流程。

运行方式很简单，在项目目录下执行：

pip install openai python evaluate_models.py

如果 API 密钥和 endpoint 配置正确，脚本会逐个调模型，最后生成一个 eval_results.json 文件。这个文件就是后续一切评测分析的基础。你可以把它交给人工评审，也可以用下面的规则脚本做自动打分。

接下来是规则评分脚本。我们先用最简单的关键词和长度规则做自动化评估。注意，规则评分非常粗糙，它只适合做初筛，真正严谨的评测需要在规则基础上引入人工审查或更强模型的裁判打分。

# score_results.py import json with open("eval_results.json", "r", encoding="utf-8") as f: results = json.load(f) def rule_score(category, output): score = 0 if len(output) > 30: score += 1 if category == "基础概念": if "强化学习" in output: score += 1 if "环境" in output or "奖励" in output: score += 1 elif category == "代码能力": if "def " in output and "return" in output: score += 1 if "[::-1]" in output or "two" in output or "循环" in output: score += 1 elif category == "逻辑推理": if "不能" in output or "无法" in output: score += 1 if "理由" in output or "因为" in output: score += 1 return score for model, items in results.items(): total = 0 for item in items: score = rule_score(item["category"], item["output"]) total += score print(f"[{model}] {item['category']}: {score} 分") avg = total / len(items) print(f"[{model}] 平均分: {avg:.2f}") print()

这段脚本的运行结果，能让你快速发现不同模型在不同类型题目上的相对表现。比如模型 A 在基础概念上得分高，但代码题得分低，说明它更适合知识问答类场景；模型 B 代码能力稳定，但概念解释不够准确，说明它可能更适合编程辅助类任务。

执行命令：

python score_results.py

到这里，一个最小可用的评测工作台就跑通了。它的价值不在于自动化程度高，而在于帮你建立了“先评测、后使用”的工程习惯。千万不要跳过这一步直接把模型丢进生产环境，尤其是当你还不清楚它在边界情况下会怎么表现的时候。

7. 模型评测与 Agent 工具调用的进阶实践

规则评分只是起点。实际项目中，模型输出往往是开放式的，用关键词匹配很容易误判。比如一个代码题，模型可能用了完全不同的实现方式，但逻辑完全正确；一个概念题，模型可能没有提到某个关键词，但因为表达清晰也值得高分。这时候就需要更灵活的评估方式。

常见做法是把规则评分升级为“强模型裁判”。让一个能力更强的模型充当考官，按照标准给候选模型的回答打分。这种模式在行业里叫 LLM-as-a-judge，也是目前很多 AI 评测平台的底层思路。关键在于考官的 prompt 要写得足够具体，评价维度要清晰，同时要防止考官模型产生位置偏见和长度偏见。

下面给一个考官 prompt 示例：

# judge_prompt.py JUDGE_SYSTEM = """ 你是一个资深技术面试官。请对以下候选回答进行客观评估。 评估维度： 1. 准确性：回答是否正确，是否存在事实错误。 2. 完整性：是否覆盖了题目要求的所有关键点。 3. 可执行性：如果是代码类回答，代码是否可以直接运行。 4. 安全性：回答是否存在安全风险或不当内容。 评分标准：每个维度 1 到 5 分，总分 4 到 20 分。 输出格式为 JSON，示例： {"accuracy": 4, "completeness": 4, "executability": 3, "safety": 5, "total": 16, "comment": "整体回答较好，但缺少边界情况处理"} """

使用裁判模型时，一个重要技巧是让考官先输出评分理由，再输出分数，这能显著提升评分质量。因为模型在列理由的过程中会重新审视回答，避免直接“拍脑袋”给分。你还可以把多个候选模型的回答打乱顺序，让考官盲评，减少位置偏见。

除了评测，Agent 工具调用是另一个值得动手的方向。现在的模型能力已经支持函数调用，也就是让模型自主决定“该调用哪个工具、传什么参数”。下面是一个简化的 Agent 示例，模型会被要求根据用户问题决定是否调用工具，工具执行完毕后，模型再基于工具结果生成最终回答。

# simple_agent.py import ast import operator import openai client = openai.OpenAI( api_key="your-api-key", base_url="https://your-model-endpoint" ) def safe_calculate(expr): """ 在可控环境内计算简单数学表达式，避免使用 eval。 只支持加减乘除和整数/浮点数，其他表达式一律拒绝。 """ operators = { ast.Add: operator.add, ast.Sub: operator.sub, ast.Mult: operator.mul, ast.Div: operator.truediv, } def _eval(node): if isinstance(node, ast.Expression): return _eval(node.body) elif isinstance(node, ast.Constant) and isinstance(node.value, (int, float)): return node.value elif isinstance(node, ast.BinOp) and type(node.op) in operators: left = _eval(node.left) right = _eval(node.right) return operators[type(node.op)](left, right) raise ValueError("不支持的表达式") return _eval(ast.parse(expr, mode="eval")) TOOLS = { "get_current_time": lambda: "2025-06-01 12:00:00", "calculate": safe_calculate, } TOOL_SCHEMAS = [ { "type": "function", "function": { "name": "get_current_time", "description": "获取当前时间", "parameters": {"type": "object", "properties": {}}, }, }, { "type": "function", "function": { "name": "calculate", "description": "计算数学表达式，例如 1 + 2 * 3", "parameters": { "type": "object", "properties": { "expr": {"type": "string", "description": "数学表达式"} }, "required": ["expr"], }, }, }, ] def run_agent(user_query): messages = [ {"role": "system", "content": "你是一个智能助手，可以调用工具解决问题。"}, {"role": "user", "content": user_query}, ] for step in range(5): resp = client.chat.completions.create( model="your-model", messages=messages, tools=TOOL_SCHEMAS, ) msg = resp.choices[0].message if not msg.tool_calls: return msg.content messages.append(msg) for call in msg.tool_calls: tool_name = call.function.name if tool_name not in TOOLS: tool_result = f"未找到工具: {tool_name}" else: try: args = json.loads(call.function.arguments) tool_result = TOOLS[tool_name](**args) except Exception as e: tool_result = f"工具执行失败: {e}" messages.append({ "role": "tool", "tool_call_id": call.id, "content": str(tool_result), }) return "达到最大迭代次数，未生成最终回答"

这里需要特别强调安全设计。计算工具没有使用 eval 函数，而是用 Python 自带的 ast 模块把表达式解析成语法树，然后只允许白名单内的运算符号。这样即使模型输出一个恶意表达式，也不会触发任意代码执行。这个设计思路在 Agent 开发中非常重要：工具函数的权限必须最小化，所有外部输入都要校验，永远不要相信模型生成的内容。

生产环境里的 Agent 会有更多的约束：工具调用鉴权、调用频率限制、敏感操作二次确认、日志审计、超时控制、失败重试等。这些细节单个看都不难，但组合起来，才是一个能在真实业务里稳定运行的 Agent 系统。

8. AI 工程化的常见误区与避坑清单

很多团队在拥抱大模型时，都会犯一些共性错误。这里整理成一张表格，供你在实际项目中对照检查。

这些坑本身并不复杂，但如果不提前预防，会消耗大量调试时间。最推荐的实践是：在项目启动阶段就搭好评测基线、日志规范和安全护栏，不要等功能上线后再补。事后补安全，成本一定是更高的。

另一个容易忽略的点是成本控制。大模型 API 按 token 计费，Agent 的多轮调用会显著放大 token 消耗。一个看似简单的 Agent 任务，可能会因为工具调用步骤多、上下文越长，产生比直接调用模型高出很多倍的成本。建议在 Agent 设计中限制最大步数、压缩上下文、使用小模型做路由、让大模型只处理关键步骤。成本优化要作为工程指标来管理，而不是等月底账单出来再惊讶。

还有一点非常重要：API 密钥绝不能硬编码在代码里。上面的示例为了方便演示，直接写了占位变量；实际项目中，密钥必须放在环境变量或密钥管理服务中，并从代码仓库中排除。最小权限原则也同样适用于模型服务：给服务分配只读权限，不上传无关数据，不把内部敏感信息放进 prompt。

9. 总结与后续学习方向

DeepMind 人才传闻这件事，最终的发展方向还不确定，也没必要去追逐每一个未经证实的细节。但这类事件反复出现，提醒了 AI 行业一个基本事实：技术会更新，组织会变动，今天最热门的模型可能在半年后被新一代取代，而真正稀缺的永远是能把不确定性变成确定性的工程能力。

这篇文章想传递的核心判断很简单。AI 行业的竞争已经从单点模型能力竞争，转向了人才、数据、算力、工程、安全的综合竞争。对谷歌这种巨头来说，留住 DeepMind 的核心人才比发布一个新模型更重要；对普通开发者来说，掌握模型评测、Agent 架构、安全护栏、成本控制这一整套 AI 工程能力，比追逐某个热门模型更重要。

如果你想继续深入，建议沿着下面几个方向延伸。第一是强化学习基础，它能帮你理解 AlphaGo、AlphaProof 这类成果背后的算法逻辑。第二是模型微调与对齐，了解 RLHF、DPO 这些技术如何让模型行为更符合预期。第三是 Agent 工作流的工程化，学习工具调用、状态管理、多智能体协作的成熟框架。第四是 AI 安全与治理，包括红队测试、幻觉检测、提示词注入防御等。第五是 MLOps 和模型生命周期管理，把训练、评测、部署、监控、回滚串成完整闭环。

最后给你一个可落地的行动建议。从这篇博客里的评测脚本开始，拿你工作中最常使用的两三个模型跑一轮对比，把结果整理成一份内部评测报告。哪怕评估维度很简单，这个过程也会逼着你想清楚：你的业务到底看重模型的哪项能力？你选的模型真的最优吗？评测结果能否支撑你做出更好的技术决策？

能把这些问题回答清楚的人，远比只会调用 API 的人值钱。建议收藏备用，然后动手跑一遍。