最近在很多技术社群里都看到“Jeff Dean 离职前最后一次对话”这个话题有人讨论他的技术视野有人讨论大模型的发展速度也有人把重点放在“创业者的唯一生路”这句话上。抛开标题里的流量叙事我觉得真正值得开发者关注的是 Jeff Dean 作为 Google AI 领域的核心人物对 AI 技术演进速度的判断发生了一次明显的修正——“我低估了 AI”。这句话放在普通读者眼里可能只是一句感叹但放在技术人眼里它其实反映了从传统机器学习时代过渡到大模型时代之后整个软件工程范式正在发生深层变化。本文不追热点不聊八卦而是从工程视角出发梳理大模型落地时真正需要关注的技术栈、架构设计、实战代码、创业壁垒和常见问题希望能给正在做 AI 应用开发的读者一些系统化的参考。1. 引言Jeff Dean 与那句话背后的技术信号1.1 Jeff Dean 在 AI 工程领域的影响力先简单介绍一下背景。Jeff Dean 是 Google 的资深研究员Google Fellow也是 Google Brain 和 Google AI 团队的早期核心成员之一。他在分布式系统、机器学习基础设施、TensorFlow、TPU 等方向都做出过关键贡献。很多早期机器学习工程师使用的第一套分布式训练方案底层思路都受 MapReduce 和 Google 分布式系统论文的影响。理解 Jeff Dean 这句话的分量要先理解他在 AI 基础设施领域的位置——他不是站在实验室里看模型效果的人而是站在基础设施层判断“一套技术能不能大规模跑起来”的人。正因如此当这样一位做基础设施出身的工程师说“低估了 AI”它不是一个普通人的感慨而是一个信号大模型的发展速度已经超出了工程基础设施的预期节奏。换到我们普通开发者的视角这句话可以翻译成——很多原来被认为“还很远”的 AI 应用场景现在已经被提前拉到了必须面对的位置。1.2 这句话真正触动的三个技术议题围绕这个标题我觉得可以提炼出三个值得展开的技术议题模型能力的演进速度远超预期原来需要专门训练一个模型的场景现在通过大模型的推理和生成能力就能覆盖。工程重心从“如何训练模型”转移到“如何把模型可靠地接入业务系统”也就是 AI 工程实践和 AI 模型部署问题。应用形态从“调用一个接口”升级为“编排多个模型和工具共同完成任务”也就是 AI Agent 开发。所以本文打算围绕“大模型应用工程化”这条主线先讲清楚大模型给软件工程带来的范式变化再给出一套可运行的 AI Agent 实战代码最后讨论创业者在 AI 浪潮里真正应该构建的壁垒。2. 从“低估 AI”出发大模型重塑了工程化范式2.1 模型能力从“识别判断”变为“生成与规划”传统机器学习时代我们训练一个模型解决的是一个具体的识别或预测问题比如图像分类、用户流失预测、推荐点击率预估。这个阶段的工程化路径比较固定采集样本、清洗数据、特征工程、训练模型、评估指标、部署上线。模型的能力边界非常明确你训练了什么任务它就只能做什么任务。大模型出现后这个路径被改变了。以 GPT 系列为代表的大模型具备了强大的文本生成、逻辑推理、代码编写、多轮对话能力。同一个模型不需要针对每个业务场景单独训练只需要通过提示词Prompt设计和上下文示例就能完成差异很大的任务。这意味着算法工程师不再需要为每个小任务单独训练模型后端工程师可以直接通过 API 把模型接入业务系统应用的功能边界从“写死的逻辑”变成了“模型推理 业务约束”。工程化范式也随之改变——核心工作从模型训练变成了模型调用、提示词管理、上下文组织和结果校验。2.2 基础设施从训练优先转向推理优先前几年 AI 基础设施建设的重点在训练侧分布式训练框架、GPU 集群调度、模型并行、混合精度训练。大模型时代虽然训练依然是基础但更多企业面对的真实问题变成了推理侧问题单次请求的推理成本如何控制响应延迟如何优化到用户可接受的范围高并发场景下如何做动态批处理和缓存模型体积很大如何在有限的显存里部署所以你会发现现在讨论 AI 模型部署时大家更关注 KV Cache、量化、vLLM、TensorRT-LLM、PagedAttention、模型蒸馏、LoRA 等技术。这些技术的目标都是同一个把大模型的推理成本降下来把响应速度提上去。对于普适性较强的应用直接使用在线 API 是成本最低的方案对于数据敏感或强合规场景可以考虑私有化部署开源模型。具体怎么选要看你的业务对延迟、成本、数据安全的要求。2.3 应用范式从单模型调用走向 Agent 化早期大模型应用比较直接把用户问题拼进 Prompt调用模型返回结果。这种模式适合问答、摘要、翻译等单轮任务。但真实业务往往是多步骤的比如用户问“帮我查一下本周的订单量并对比上周”系统需要先调用订单查询 API再把查询结果交给模型做对比总结用户问“这个合同里有没有风险条款”系统需要先解析文档再结合风险规则判断最后生成报告用户问“帮我订一张明天去北京的机票”系统需要查询航班、比价、下单每一步都需要外部工具配合。这种场景下单纯一次模型调用解决不了问题。于是出现了 AI Agent 的概念——模型作为“大脑”负责任务拆解、工具选择、结果汇总外部 API、数据库、搜索引擎作为“手脚”负责执行具体动作。Agent 化带来的工程挑战也很明显如何设计工具描述让模型能准确选择合适的工具如何管理多轮对话中的上下文避免超过模型窗口限制如何防止模型在循环里反复调用工具如何设置最大迭代次数如何校验工具返回结果的正确性如何兜底这些问题都需要工程手段解决也是本文实战部分要演示的内容。3. 大模型应用的技术选型与整体架构3.1 先根据业务场景确定技术路线在写代码之前先想清楚你的应用属于哪种类型不同类型的技术路线差异很大应用类型典型场景推荐方案文本问答知识库问答、文档问答RAG检索增强生成 向量数据库内容生成文案写作、周报生成Prompt 模板 模型 API结构化数据操作数据分析、报表生成NL2SQL / 工具调用客服对话售前咨询、售后处理多轮对话 工单系统 API复杂任务执行自动下单、跨系统操作Agent 编排 工具注册代码辅助代码生成、Code Review代码模型 代码仓库 API如果你的业务有大量私有文档知识优先考虑 RAG如果你的业务需要操作多个外部系统优先考虑 Agent如果只是纯文本处理直接用模型 API 加合理的 Prompt 管理就够了。不要为了“用 Agent 而用 Agent”复杂度越高排查问题越难。3.2 一个可落地的 AI 应用技术栈参考目前比较常见的大模型工程实践一套从零到一可落地的技术栈大致包括这几层接入层Nginx、API 网关、限流熔断组件应用服务层PythonFastAPI / Flask或 JavaSpring Boot模型层云端大模型 API 或私有化部署的开源模型检索层向量数据库如 Milvus / pgvector / Chroma、ES编排层自研 Agent 流程或 LangGraph、Dify、Coze 等平台可观测层日志、指标监控、链路追踪、Token 成本统计这里需要注意选型要结合团队的技术储备。如果团队后端以 Java 为主强行引入 Python Agent 框架会增加维护成本反过来如果项目主要逻辑就是调用模型 API用 Python 写脚本会更轻量。3.3 架构分层示意用一张简单的分层示意来展示大模型应用的整体结构[ 用户端 / 客户端 ] │ [ 接入层网关 / 限流 / 鉴权 ] │ [ 应用服务层业务逻辑 / Prompt 管理 / 任务编排 ] │ [ Agent 调度层模型调用 / 工具注册 / 上下文管理 ] │ [ 模型层 ] --- [ 检索层 ] --- [ 外部工具 / API ]这样的分层结构好处是每一层职责清晰方便独立扩展模型层可以随时替换不影响上层业务外部工具独立管理Agent 只是调度器不耦合具体实现接入层统一处理鉴权和限流避免模型 API 被刷。4. 完整实战一个可运行的技术问答 Agent下面进入核心环节。为了让你能直接照着操作这里实现一个简化但完整的技术问答 Agent支持两件事根据知识库内容回答技术问题调用外部工具这里用一个时间查询工具和一个简单的文档检索工具来补充信息。整个项目用 Python 编写模型接口以兼容 OpenAI 协议的 API 为例。如果你使用的是其他模型服务商只要能兼容同样的接口格式代码基本可以复用。4.1 环境准备与项目结构建议使用 Python 3.10 以上版本并创建一个虚拟环境mkdir ai-agent-demo cd ai-agent-demo python3 -m venv venv source venv/bin/activate安装依赖项目依赖很少主要是 openai SDK 和 python-dotenvpip install openai python-dotenv项目结构如下ai-agent-demo/ ├── .env ├── requirements.txt ├── config.py ├── llm_client.py ├── tools.py ├── agent.py └── main.pyrequirements.txt 内容openai1.0.0 python-dotenv1.0.0版本可以根据你的实际环境调整这里只列出主版本范围重点演示配置思路。4.2 创建配置文件 config.py配置文件负责统一管理模型参数和环境变量# 文件路径config.py import os from dotenv import load_dotenv load_dotenv() # 模型服务配置 # 如果你使用的是在线 API这里填入对应的 base_url 和 api_key # 如果你使用的是本地部署的 OpenAI 兼容服务也可以把 base_url 指向本地地址 MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini) API_KEY os.getenv(API_KEY, ) BASE_URL os.getenv(BASE_URL, https://api.openai.com/v1) # Agent 配置 MAX_ITERATIONS int(os.getenv(MAX_ITERATIONS, 5)) TEMPERATURE float(os.getenv(TEMPERATURE, 0.3))这里把配置集中到一个文件后续如果需要调整模型、修改温度参数不需要改动业务代码。实际项目中配置应该放到配置中心或环境变量管理平台避免把密钥提交到代码仓库。4.3 封装模型调用 llm_client.py模型调用层需要处理三件事构造消息、调用接口、处理异常。# 文件路径llm_client.py from openai import OpenAI from config import API_KEY, BASE_URL, MODEL_NAME, TEMPERATURE class LLMClient: def __init__(self): self.client OpenAI(api_keyAPI_KEY, base_urlBASE_URL) self.model MODEL_NAME def chat(self, messages, temperatureTEMPERATURE): try: resp self.client.chat.completions.create( modelself.model, messagesmessages, temperaturetemperature, ) return resp.choices[0].message.content except Exception as e: # 生产环境建议记录完整异常日志这里只做简单打印 print(f模型调用异常: {e}) return None这里使用了 OpenAI Python SDK 的标准调用方式。需要注意不同的 SDK 版本在参数上会有细微差异如果你安装的版本较新部分参数可能已经调整建议以官方文档为准。4.4 定义工具层 tools.py工具层是 Agent 与外部系统交互的桥梁。为了让模型能理解每个工具是干什么的还需要提供一份工具描述字典。# 文件路径tools.py from datetime import datetime def get_current_time(): 获取当前时间 return datetime.now().strftime(%Y-%m-%d %H:%M:%S) def get_tool_schema(): 返回工具描述供模型选择工具时使用 return [ { type: function, function: { name: get_current_time, description: 获取当前日期和时间当用户询问时间相关问题时使用, parameters: { type: object, properties: {}, required: [] } } } ] TOOL_MAP { get_current_time: get_current_time, }在这个示例中工具是一个时间查询函数。实际项目中get_current_time 可以替换为订单查询、库存查询、文档检索等真实业务函数。工具描述里的 name 和 description 非常关键模型会依靠这些描述决定调用哪个工具所以描述要写得准确、清晰。4.5 实现 Agent 编排逻辑 agent.pyAgent 的核心逻辑是循环判断模型是否需要调用工具如果需要就执行工具并把结果返回给模型如果模型认为信息够了就生成最终回答。# 文件路径agent.py import json from llm_client import LLMClient from tools import TOOL_MAP, get_tool_schema from config import MAX_ITERATIONS class Agent: def __init__(self): self.llm LLMClient() self.messages [] self.tool_schema get_tool_schema() def reset(self, system_prompt, user_input): 初始化对话上下文 self.messages [ {role: system, content: system_prompt}, {role: user, content: user_input}, ] def run(self, system_prompt, user_input): self.reset(system_prompt, user_input) for step in range(MAX_ITERATIONS): # 调用模型 resp self.llm.client.chat.completions.create( modelself.llm.model, messagesself.messages, toolsself.tool_schema, tool_choiceauto, ) msg resp.choices[0].message # 如果没有工具调用请求说明模型可以直接回答 if not msg.tool_calls: self.messages.append({ role: assistant, content: msg.content, }) return msg.content # 如果有工具调用请求执行工具并把结果追加到上下文 self.messages.append({ role: assistant, content: msg.content, tool_calls: [ { id: tc.id, type: function, function: { name: tc.function.name, arguments: tc.function.arguments, }, } for tc in msg.tool_calls ], }) for tc in msg.tool_calls: func_name tc.function.name func TOOL_MAP.get(func_name) if not func: result f未找到工具: {func_name} else: try: arguments json.loads(tc.function.arguments or {}) result func(**arguments) except Exception as e: result f工具执行异常: {e} self.messages.append({ role: tool, tool_call_id: tc.id, content: str(result), }) return 已达到最大迭代次数请简化问题后重试。这个实现里有几个关键点需要注意tool_choiceauto表示由模型自主决定是否调用工具工具执行结果必须通过role: tool的消息返回给模型模型才能结合结果生成最终答案一定要设置最大迭代次数防止模型在工具调用中陷入死循环工具执行阶段的异常要捕获并返回给模型让模型知道工具执行失败而不是直接崩溃。4.6 编写主程序 main.py主程序负责读取用户输入并启动 Agent# 文件路径main.py from agent import Agent SYSTEM_PROMPT 你是一个技术问答助手。你可以使用外部工具获取实时信息。 如果用户的问题不涉及当前时间你不需要调用工具直接回答即可。 回答要简洁、准确、结构化。 def main(): agent Agent() print(欢迎使用 AI Agent 演示输入 exit 退出。) while True: user_input input(\n你: ) if user_input.strip().lower() in (exit, quit): break answer agent.run(SYSTEM_PROMPT, user_input) print(f\nAgent: {answer}) if __name__ __main__: main()这里把系统提示词放在主程序里是为了方便调整。实际项目中系统提示词往往需要根据业务场景做多版本管理和线上灰度建议存放在独立的 Prompt 管理模块中。4.7 运行与验证在项目根目录执行python main.py假设模型服务配置正确输入一个不需要工具的问题你: Python 列表和元组的区别是什么预期输出模型结合自身知识直接回答不调用工具。再输入一个时间相关的问题你: 现在几点了预期输出模型识别出需要调用get_current_time工具执行后返回当前时间再结合时间生成回答。如果你在日志中看到工具调用的过程说明 Agent 工作正常。这个示例虽然简单但已经完整覆盖了模型调用、工具注册、上下文管理、异常兜底这几个 Agent 开发的核心环节。4.8 成本与性能说明使用大模型 API 时成本与性能是必须关注的指标。一个简单估算公式单次请求成本 ≈ 输入 Token 数 × 输入单价 输出 Token 数 × 输出单价Agent 场景下每轮迭代都会把历史消息重新发送给模型所以上下文越长、迭代次数越多成本越高。优化方向包括精简系统提示词去掉不必要的内容控制工具描述的长度引入滑动窗口或摘要压缩避免上下文无限增长对简单问题设置更低的模型档位对复杂问题才使用更强模型。刚才的示例是单机脚本生产环境还需要考虑并发控制、异步调用、超时重试、限流熔断等能力。这些能力在不同框架里实现方式不同但思路是通用的。5. 创业者的“唯一生路”壁垒到底在哪里5.1 为什么“套壳”很难持久回到话题本身“创业者的唯一生路”如果放在工程视角看我觉得核心并不在于“第一个做出 AI 应用”而在于“能否建立持续的工程壁垒”。市面上的模型 API 越来越同质化单纯封装一个模型接口、做一层漂亮的前端界面这种“套壳”应用的护城河非常低。模型服务商一旦推出官方版本或者价格战开始小团队很难招架。那么壁垒在哪里通常在四个方面数据壁垒是否有别人拿不到的私有数据或者能形成数据飞轮的业务闭环场景壁垒是否在某个垂直行业里深耕过流程Know-how 不在模型里而在业务规则里工程壁垒是否有稳定的模型评测体系、成本控制体系、高质量的工具链交付壁垒是否能把 AI 能力打包成客户愿意持续付费的完整方案而不是一个 Demo。5.2 垂直场景与数据飞轮大模型是通用能力但业务价值往往发生在垂直场景。比如同样都是文档问答通用工具只能回答公开知识而如果你能接入企业内部的项目文档、会议纪要、运维工单做出来的问答系统对特定企业的价值会远高于通用工具。更关键的是数据飞轮用户在使用 Agent 的过程中会产生大量反馈数据这些数据经过清洗、标注后可以用于优化 Prompt、微调模型或者改进工具调度逻辑。这是跑得越久、壁垒越高的事情也是“套壳”应用不具备的特质。所以在做 AI 应用时建议优先想清楚一个问题你的产品在使用过程中是否能持续沉淀高质量数据如果答案是不能那长期来看很难形成竞争力。5.3 评测体系是护城河很多 AI 应用项目死在“Demo 效果很好上线一测稀碎”。原因在于缺少评测体系。模型是非确定性的同样的输入可能产生不同的输出没有评测体系就无法判断一个 Prompt 修改到底是变好了还是变坏了。一个轻量级的评测方案是准备一组覆盖典型场景的评测用例每次变更 Prompt、工具逻辑或模型版本后跑一遍评测集对比输出质量。下面给出一个简化版的评测脚本片段# 文件路径evaluate.py核心片段需根据实际场景调整 from agent import Agent test_cases [ {input: Python 列表和元组的区别, contains: [可变, 不可变]}, {input: HTTP 500 状态码是什么意思, contains: [服务器, 错误]}, ] agent Agent() for case in test_cases: answer agent.run( system_prompt你是一个技术问答助手。回答要简洁准确。, user_inputcase[input], ) hit all(kw in answer for kw in case[contains]) print(f用例: {case[input]}\n通过: {hit}\n回答: {answer}\n)这个脚本只是示例思路你可以根据自己的业务定义更复杂的评分标准比如引入 LLM-as-Judge让一个更强的模型来评判回答质量也可以统计工具调用成功率、平均延迟、单次成本等指标。评测体系越完善你在迭代时越有底气。5.4 成本与合规创业公司尤其要重视创业公司在 AI 项目上容易忽视的两件事是成本和合规。成本方面建议从第一天起就做 Token 计量和预算告警。可以在模型调用层埋点统计每次请求的输入输出 Token 数、模型名称、业务来源每天汇总一次成本报告。没有成本意识的项目很容易在用户量增长时发现费用失控。合规方面涉及用户隐私、数据出境、大模型内容安全等风险时需要特别注意。大模型生成内容具有不确定性一定要在应用层做好内容安全过滤、敏感信息脱敏、人工审核机制。涉及真实业务数据的操作必须坚持最小权限原则并且所有操作都要留痕。触达用户的内容建议保留人工复核入口不能完全交给模型自动发布。这些点听起来基础但在生产事故中往往是致命问题。6. 常见问题与排查思路这里把大模型应用开发中比较常见的问题整理成表格你可以按图索骥问题现象常见原因解决思路模型返回内容与业务无关系统提示词不够明确优化系统提示词加入角色、任务边界、回答格式多轮对话后回答质量变差上下文过长或引入无关内容做上下文裁剪、摘要压缩、重置对话工具调用不触发工具描述不清晰重写工具 name 和 description补充典型触发场景工具调用循环死循环缺少最大迭代限制设置 MAX_ITERATIONS超限强制结束响应速度很慢模型输入过长、网络延迟精简 Prompt、使用流式输出、考虑模型缓存并发一高就报错API 限流或服务端超时加本地限流、重试、熔断必要时做多模型切换成本增长过快上下文重复发送、用户高频调用控制上下文长度、加缓存、做配额管理内容输出包含不合适内容模型偏差、缺少内容审核增加内容安全过滤层接入审核服务必要时人工复核私有化部署 GPU 显存不足模型参数量超过显存使用量化部署、选择更小模型、做模型分片如果你遇到模型回答不符合预期有一个通用排查顺序先检查输入消息是否完整再检查提示词是否清晰然后检查工具描述和返回结果最后检查模型版本和参数。大多数问题都是出在这几层之间而不是模型本身“笨”。7. 最佳实践与工程建议7.1 上线前检查清单把 AI 应用从开发环境推到生产环境之前强烈建议过一遍下面的清单模型 API 的 Key 是否已注入环境变量或密钥管理服务而不是写在代码里是否设置了请求超时、重试、限流、熔断是否有 Token 成本统计和预算告警是否建立了覆盖核心场景的评测集是否做了内容安全过滤和敏感信息脱敏是否对用户输入做了长度限制和频率限制工具调用是否有权限校验外部 API 的调用是否有审计日志模型返回结果是否有基本的格式校验和兜底提示这条清单里的每一项都可能在生产环境中引发事故。不要以为 AI 应用的部署和普通 Web 应用一样多加一个模型接口就行模型的不确定性会把很多隐患放大。7.2 架构演进路线如果你的项目只是一个小 Demo直接用刚才的脚本就够了。但项目逐渐成熟后架构演进可以参考这个路径阶段一脚本或单体应用直接调用模型 API适合验证功能阶段二引入 FastAPI / Spring Boot 等服务框架支持多用户接入增加鉴权和数据存储阶段三抽出独立的 Agent 编排层支持多模型切换、工具注册中心、Prompt 管理阶段四增加可观测体系包括日志采集、链路追踪、成本统计、评测平台阶段五根据业务需要引入 RAG、向量数据库、微调流水线形成完整的 AI 中台能力。不建议一上来就搭建庞大的 AI 中台。很多团队在第一阶段就试图做出大而全的平台结果功能没验证就背上了沉重的工程包袱。先快速跑通业务闭环再逐步补充基础设施是更稳妥的选择。7.3 关注 AI 工程化的长期学习路线回到本文开头的那个话题如果说 Jeff Dean 那句话给了我们什么启示我觉得是AI 的发展速度已经不允许我们再用“观望”的态度对待它。无论你是一名后端工程师、算法工程师还是创业者下一个阶段的核心竞争点都在 AI 工程化能力上。学习路线上建议按这个顺序展开先掌握大模型 API 的基础调用方式理解 Token、温度、上下文这些概念再学习 Prompt 工程掌握角色设定、Few-shot、思维链等方法然后学习 RAG 检索增强生成掌握向量化、向量检索、重排等流程接着学习 Agent 编排理解工具调用、多步推理、记忆管理最后深入模型部署与优化接触量化、推理加速、成本优化结合你自己的业务场景选一条垂直方向深耕。技术变化很快但工程化的底层能力是相通的清晰的问题拆解、严谨的评测验证、稳定的系统设计这些在任何技术浪潮里都不会过时。如果你正准备用大模型做一个产品或项目我的建议是不要被“低估 AI”或者“唯一生路”这样的标题裹挟静下心来把你最熟悉的一个业务场景用最少的技术方案先跑出一个闭环。先跑通再优化再谈壁垒。这是做 AI 工程最实际的一条路。