最近 AI 圈子里有一类讨论很值得玩味一边是亦庄的产业对接会技术团队和企业坐在一起聊“AI 怎么真正落进生产线”另一边是杭州的辩论场年轻人围绕 AI 的技术路线、创业方向和应用价值争得不可开交。两个场景看起来完全不搭但它们指向的其实是同一个问题——当大模型能力越来越容易被调用什么才是 AI 的“真问题”36氪把这题交给了年轻人。对开发者来说这道题不是辩论赛上的立场选择而是每天要面对的实际工程问题模型调用通了没有Agent 能不能稳定执行任务服务放到线上能不能扛住并发这些技术细节才是“AI 落地”真正的翻译方式。1. 从亦庄到杭州AI“真问题”被摆上台面1.1 亦庄的对接会产业侧的落地焦虑亦庄是北京制造业、自动驾驶和智能硬件产业比较集中的区域。这里的对接会通常不是“技术布道”现场更像是一场需求撮合企业带着业务场景来技术团队带着模型、算力和方案来双方共同回答一个问题——AI 在具体业务线上到底能不能降本能不能增效。参与过类似对接的开发者都会有同感产业方不太关心你的模型是 Transformer 还是 MoE他们只关心三件事效果是否稳定、成本是否可控、能不能接入现有的业务流程。这意味着 AI 工程师的能力模型正在发生变化过去“会调模型”或许足够现在则需要理解业务、设计提示词、编排工具调用、处理异常、完成部署。这场对接会本质上是一个信号AI 技术红利正在从算法研究端向工程应用端转移。1.2 杭州的辩论场年轻人在争什么杭州是互联网生态和创业文化很浓厚的城市辩论这种形式天然适合讨论没有标准答案的问题。当 36氪把舞台交给年轻人辩题大概率会集中在几个方向AI 应用开发究竟是技术驱动还是场景驱动年轻开发者应该先深入算法还是先做产品AI 创业的机会在通用模型还是在垂直行业。这些话题放到开发者的真实处境里其实就是职业路径选择问题。有人担心自己只会调用 API没有核心竞争力有人觉得模型能力会越来越强应用层开发门槛会越来越低也有人认为正因为门槛降低能把模型改造成可用产品的人才反而更稀缺。辩论最有价值的不是结论而是把模糊的焦虑变成清晰的问题。这些问题落到程序员键盘上会转变成更具体的技术选择要不要学 LangChain该不该研究 RAG是直接使用模型 API 还是自己部署开源模型先做 Prompt 优化还是先做服务架构1.3 真问题不是模型而是工程化如果把两场活动放在一起看所谓“AI 真问题”已经浮出水面模型能力不再是唯一瓶颈真正的瓶颈是工程化能力。最近一两年大模型的推理能力、上下文长度、多模态能力都明显提升不同模型之间的实际体验差距在缩小。对大多数业务场景来说问题不是“模型不够聪明”而是“怎么把模型接入系统、怎么控制 token 成本、怎么保证响应延迟稳定、怎么评估效果好坏”。这些都是典型的工程问题。AI 工程实践的话题也因此变得重要。一个可以跑通的 Demo和一套能稳定运行的服务中间隔着大量细节异常处理、超时重试、数据脱敏、日志监控、版本回滚。这也是为什么很多技术团队在招人时越来越看重“能不能把一个东西从零部署上线”的完整经验。2. 把话题翻译成技术AI 工程实践的几个核心方向2.1 AI 应用开发从“调 API”到“做产品”AI 应用开发是绝大多数开发者接触 AI 的第一站。很多人以为 AI 应用开发等于写一行代码调用大模型接口实际远没这么简单。一个完整的 AI 应用开发链路通常包括需求拆解、Prompt 设计、数据准备、接口编排、前后端集成、效果评估、灰度发布。以智能客服为例你需要让模型理解用户意图从订单系统查询数据再根据规则生成回答整个过程还要考虑节假日话术、敏感词过滤、多轮上下文等边界情况。在辩论场上聊“应用为王”落到代码里就是这些工程琐事。谁能把琐事处理好谁的应用体验就会更稳定。2.2 AI Agent从“对话”到“执行”AI Agent智能体是近两年 AI 应用开发中增长最快的方向之一。和普通聊天机器人不同Agent 不只是“生成文字”而是把大模型当作大脑通过调用工具完成真实任务。比如一个客服 Agent需要完成这些步骤解析用户问题判断是否需要查订单调用订单查询接口拿到结果后生成回复。如果用户问的是“我的快递到哪了”Agent 需要知道调用什么工具、传什么参数、如何处理工具返回的数据。Agent 开发的核心技术点包括工具调用Function Calling、记忆管理、任务规划、异常恢复。这里的难点在于稳定性模型可能误解用户意图可能传错参数也可能在中间步骤失败。工程化的 Agent 开发本质上是在和不确定性做对抗。2.3 AI 模型部署从开发环境到生产环境模型部署是 AI 工程实践的“最后一公里”也是很多开发者最陌生的部分。一个 Jupyter Notebook 里跑通的模型距离生产环境还有相当大的距离。生产环境需要推理服务、GPU 或 API 资源、并发控制、监控告警还要考虑冷启动、弹性伸缩、成本核算。以开源模型本地部署为例你需要选择推理框架处理显存占用配置 Docker 容器甚至要做模型量化来降低资源需求。幸运的是部署工具链也在快速成熟。FastAPI 可以快速封装推理接口Docker 可以统一运行环境云服务商提供了 GPU 容器镜像监控平台也能直接接入模型服务的指标。对年轻开发者来说掌握这些工具比掌握复杂的模型训练技巧更容易形成竞争力。2.4 AI 工程实践为什么是年轻人的机会大厂有算法团队和算力优势但 AI 落地的需求分散在各个行业、各个中小团队中。这些场景往往不需要从零训练模型而是需要有人能把现成模型快速接入业务做成真正可用的工具。这种“快速落地”的能力恰恰是年轻开发者可以快速积累的。你不需要发表顶会论文只需要完整做过两三个 AI 应用项目熟悉 API 调用、Agent 搭建、服务部署、问题排查就已经比很多只停留在“体验过 ChatGPT”的人更有竞争力。所以 36氪把题目交给年轻人不是一句口号。它对应着真实的人才需求AI 行业不缺讨论者缺的是能把问题拆解成代码、把代码变成产品的人。3. 环境准备与版本说明在进入实践之前先把开发环境准备好。本文后续示例以 Python 为主涉及大模型 API 调用、Agent 最小实现和 Docker 服务部署。3.1 本地开发环境清单建议准备以下环境操作系统Windows 10/11、macOS 或 Linux 均可命令差别不大Python建议 3.10 或 3.11 版本避免部分依赖库兼容问题Docker用于服务部署示例本地开发可以先不安装IDEVS Code、PyCharm 等都可以重点是对 Python 语法高亮支持好大模型 API准备一个可用的 API Key官方服务或兼容 OpenAI 协议的第三方服务均可版本说明AI 相关 Python 库更新速度很快本文不把版本号写死。建议使用pip install -U安装最新稳定版如果在公司项目中使用则以项目 lock 文件为准。3.2 推荐项目结构为了方便理解后续示例统一放在一个项目中。目录结构如下ai-practice/ ├── .env ├── requirements.txt ├── demo_api.py ├── agent_demo.py └── server/ ├── main.py └── Dockerfile各文件作用.env存放环境变量主要是 API Keyrequirements.txtPython 依赖清单demo_api.py大模型 API 调用示例agent_demo.py最小 Agent 示例server/main.pyFastAPI 服务server/Dockerfile容器部署配置4. 实战一用一次 API 调用理解 AI 应用开发链路不管辩论赛上怎么定义 AI 应用落到实际开发第一步永远是“把模型接口跑通”。这是最基础、也最必要的环节。4.1 创建虚拟环境并安装依赖建议每个项目都使用独立虚拟环境避免多个项目互相污染依赖。cd ai-practice python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate pip install openai python-dotenvopenai是官方 Python SDKpython-dotenv用于读取.env文件中的环境变量。4.2 配置环境变量在项目根目录创建.env文件OPENAI_API_KEY你的密钥 OPENAI_BASE_URLhttps://api.openai.com/v1 OPENAI_MODELgpt-4o-mini注意.env文件不要提交到 Git 仓库建议在.gitignore中忽略它。如果使用国内兼容 OpenAI 协议的模型服务把OPENAI_BASE_URL换成服务商提供的地址即可。这里的OPENAI_MODEL是模型名称不同服务商支持的模型名不同需要根据实际情况调整。示例中使用gpt-4o-mini只是演示不代表推荐。4.3 编写调用代码创建demo_api.pyimport os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) def chat_once(prompt: str) - str: try: resp client.chat.completions.create( modelos.getenv(OPENAI_MODEL, gpt-4o-mini), messages[ {role: system, content: 你是一名严谨的AI工程助手回答尽量简洁。}, {role: user, content: prompt}, ], temperature0.3, ) return resp.choices[0].message.content except Exception as e: return f调用失败{e} if __name__ __main__: result chat_once(请用一句话说明AI应用开发和模型训练的区别。) print(result)这段代码做了几件事从.env读取 API Key避免硬编码创建OpenAI客户端支持自定义base_url构造 system 和 user 消息这是最基础的 Prompt 结构设置temperature0.3让回答更稳定、更少随机捕获异常保证程序不会因为网络问题直接崩溃temperature是一个重要参数数值越高回答越有创造性越低越稳定。做工程化应用时通常建议设置在 0.2 到 0.5 之间。4.4 运行与预期结果python demo_api.py预期会输出一句类似“AI应用开发关注如何利用现成模型构建产品而模型训练关注如何从数据中训练出模型”的话。不同模型和 Prompt 下具体内容会有差异但只要能打印出回答就说明整条链路已经打通。这里其实涵盖了 AI 应用开发最核心的路径获取输入构造 Prompt调用模型处理输出。后续所有复杂应用都是在这个链条上增加逻辑。5. 实战二实现一个最小可运行的 AI Agent理解了 API 调用之后可以再往前一步尝试实现一个最小可运行的 Agent。这个示例不依赖复杂框架用纯 Python 就能跑通目的是理解 Agent 的核心机制。5.1 Agent 的核心组成一个最小 Agent 由三部分组成组成作用示例模型理解用户意图、生成决策大模型 API 或本地模型工具执行具体动作查天气、查订单、发邮件主循环把模型输出转成工具调用解析 JSON、执行函数流程可以简单理解为用户提问 - 模型分析 - 发现需要工具 - 调用工具 - 返回结果。因为没有使用任何外部 Agent 框架所以这个示例更容易看到本质。5.2 编写最小 Agent 代码创建agent_demo.pyimport json TOOLS { get_weather: { description: 查询城市天气, handler: lambda city: f{city}今天多云气温23℃, }, get_order_status: { description: 查询订单状态, handler: lambda order_id: f订单{order_id}正在配送中, }, } def local_model(prompt: str) - str: 模拟模型决策真实项目中这里会调用大模型API。 if 天气 in prompt: return json.dumps({tool: get_weather, args: {city: 杭州}}, ensure_asciiFalse) if 订单 in prompt: return json.dumps({tool: get_order_status, args: {order_id: A10086}}, ensure_asciiFalse) return json.dumps({tool: None, args: {}}) def run_agent(prompt: str) - str: response local_model(prompt) try: call json.loads(response) except json.JSONDecodeError: return 模型输出无法解析 tool call.get(tool) if tool is None: return 抱歉我没有找到合适的工具。 args call.get(args, {}) handler TOOLS[tool][handler] return handler(**args) if __name__ __main__: print(run_agent(杭州天气怎么样)) print(run_agent(帮我查一下订单A10086的状态))这段代码的核心逻辑是模型返回一个 JSON 格式的“决策”主循环解析 JSON找到对应工具并调用。真实项目中local_model的位置会替换为一次完整的大模型 API 调用模型返回的结构通常也是类似的 JSON。5.3 运行验证python agent_demo.py预期输出杭州今天多云气温23℃ 订单A10086正在配送中这说明 Agent 已经能根据用户输入选择工具并返回结果。虽然工具是模拟的但整个“决策-调用-返回”闭环是真实的。5.4 真实场景中的 Function Calling如果使用支持 Function Calling 的模型可以直接在 API 请求中声明工具让模型返回结构化的工具调用参数。示意如下resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: user, content: 杭州天气怎么样} ], tools[{ type: function, function: { name: get_weather, description: 查询城市天气, parameters: { type: object, properties: { city: {type: string} }, required: [city], }, }, }], )这种方式比“让模型自由生成 JSON”更稳定因为工具参数由模型的接口层约束不容易产生格式错误。实际开发中推荐优先使用模型的 Function Calling 能力而不是单纯依赖 Prompt 约束。6. 实战三把 AI 能力部署成线上服务一个 AI 功能在本地跑通只是开始让别人能通过 HTTP 接口访问才算完成一个最小可交付的闭环。这里用 FastAPI 封装一个简单的 AI 服务并用 Docker 完成容器化部署。6.1 编写 FastAPI 接口创建server/main.pyfrom fastapi import FastAPI from pydantic import BaseModel app FastAPI(titleAI Demo Service) class ChatRequest(BaseModel): prompt: str app.get(/health) def health(): return {status: ok} app.post(/chat) def chat(req: ChatRequest): # 演示逻辑真实项目中在这里调用模型API return {reply: f你发送的是{req.prompt}}这里把/chat接口的返回逻辑简化了真实项目可以在chat函数中调用第 4 节的chat_once。不过要注意同步调用大模型 API 会阻塞请求线程生产环境通常会改成异步任务或消息队列。同时创建server/requirements.txtfastapi0.110.0 uvicorn0.29.0 pydantic2.0.0版本号使用区间范围具体以安装时实际解析到的最新稳定版为准。6.2 编写 Dockerfile创建server/DockerfileFROM python:3.11-slim WORKDIR /app COPY requirements.txt /app/requirements.txt RUN pip install --no-cache-dir -r /app/requirements.txt COPY . /app EXPOSE 8000 CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000]注意事项示例假设 Dockerfile 和main.py在同一个目录即server目录下因此 CMD 中使用main:app。如果把main.py放在子目录需要调整模块路径。6.3 构建、运行与验证在server目录下执行docker build -t ai-demo . docker run -d --name ai-demo -p 8000:8000 ai-demo然后用curl验证服务curl http://localhost:8000/health预期输出{status:ok}再测试/chat接口curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {prompt: 你好}预期输出类似{reply:你发送的是你好}到这里一个 AI 服务已经完成了从代码到容器的部署闭环。如果要在容器中调用真实模型接口推荐通过环境变量注入 API Keydocker run -d --name ai-demo -p 8000:8000 --env-file ../.env ai-demo这样可以避免把密钥写进镜像。7. 常见问题与排查思路AI 工程实践的报错和传统后端有些不同很多问题来自模型接口、依赖库和资源限制。下面整理一份高频问题排查表。7.1 高频问题排查表问题现象常见原因解决思路API 返回 401 或 403API Key 无效、未设置或权限不足检查.env文件、环境变量和账户权限请求一直超时网络限制或base_url配置错误检查网络连通性确认接口地址是否正确中文乱码控制台编码问题在命令前设置PYTHONIOENCODINGutf-8模型回答与预期不符Prompt 设计不合理或温度过高优化 system prompt降低temperatureDocker 构建很慢依赖包下载慢配置 pip 镜像源利用 Docker 层缓存容器启动后无法访问端口映射或监听地址错误检查docker run -p确认--host 0.0.0.0Agent 工具调用失败模型返回的 JSON 格式不对使用 Function Calling 替代自由文本输出7.2 典型问题排查演示以“API 返回 401”为例推荐按这个顺序排查确认.env文件是否存在是否被load_dotenv()加载在代码中临时打印os.getenv(OPENAI_API_KEY)是否为空确认 API Key 是否有效可以在服务商后台查看调用记录检查是否从错误的环境复制了 Key比如把测试环境的 Key 用到了生产环境这里要特别强调API Key 是敏感信息不要把密钥直接打印到日志或提交到代码仓库。排查时可以打印但排查完要立刻删除相关日志。8. 最佳实践与工程建议8.1 密钥与安全边界AI 应用开发中密钥管理是第一优先级。API Key 只能存放在后端环境变量或密钥管理服务中绝不能写进前端代码。如果应用是 Web 服务建议由后端统一调用模型接口不要让浏览器直接携带密钥访问模型服务。同时要注意数据边界用户输入可能包含敏感信息调用第三方模型前要做脱敏处理。金融、医疗等行业的项目还要额外评估数据出境和合规风险。8.2 可观测性与效果评估模型接口与传统接口最大的区别是“结果不确定”。传统接口返回是确定的单元测试就能验证模型接口每次调用都可能不同所以必须建立自己的评估方式。推荐的做法是记录每次请求的输入输出、响应延迟、token 消耗和异常信息。积累一段时间后把效果不好的样本收集成 bad-case 库用这批样本去回归测试新的 Prompt 或模型版本。没有评估体系AI 应用的优化就无从谈起。8.3 Prompt 与版本管理Prompt 是 AI 应用重要的“配置代码”。实际项目中Prompt 应该像代码一样纳入版本管理。Prompt 的每一处修改都要有对应的版本记录、修改原因和测试结果。建议在项目中使用单独的文件维护 Prompt 模板而不是散落在业务代码中。统一目录管理之后上线前的评审和上线后的回滚都会更方便。8.4 从 Demo 到生产的四道坎第一道坎是性能。Demo 只服务一个人生产环境要面对并发请求。模型推理的延迟直接影响用户体验必要时需要引入缓存、异步任务或横向扩容。第二道坎是成本。大模型 API 按 token 计费Prompt 越长、调用次数越多成本越高。优化方向包括精简 Prompt、减少不必要的历史记录、对长文本做摘要。第三道坎是稳定性。模型服务可能限流、超时、返回异常格式代码里必须有重试、降级和兜底方案。对于核心流程要避免模型接口故障拖垮整个业务。第四道坎是合规。开源模型有自己的许可证在线 API 有自己的使用条款用户数据有自己的隐私要求。上线前需要把这些边界梳理清楚。9. 总结与学习路线9.1 本文核心收获从亦庄的对接会到杭州的辩论场AI 的真问题不是抽象的概念而是一个个具体的工程环节。本文通过三个最小示例展示了 AI 应用开发的三条主干链路大模型 API 调用是最基础的接入方式Agent 最小实现揭示了工具调用的核心机制FastAPI 与 Docker 部署完成了从代码到服务的闭环掌握这三条链路就等于掌握了 AI 工程实践的基本骨架。9.2 建议学习路线如果你准备系统学习 AI 应用开发可以参考下面的顺序阶段学习内容实践目标第一阶段Python 基础与虚拟环境能独立编写和运行脚本第二阶段大模型 API 调用与 Prompt 工程能完成一个问答机器人第三阶段RAG 与检索能基于本地文档做知识库问答第四阶段Agent 与工具调用能实现多工具协作的智能体第五阶段服务化部署能用 Docker 部署自己的 AI 服务第六阶段参与开源项目在真实维护的代码中积累工程经验每个阶段之间都有明确的项目产出。不要追求“学完再动手”AI 工程实践里最重要的一步是尽早把第一段代码跑起来。9.3 最后说一句辩论场上AI 的未来可以有很多种讲法但代码世界里AI 的落地只有一条路动手实践。与其纠结“技术是不是王道”“应用是不是风口”不如先跑通一次 API 调用再实现一个 Agent最后把服务部署上线。真问题不一定有标准答案但调试成功的日志会是最好的回答。