如果你是 2016 年之后才开始接触 AI 的技术人可能很难理解“Move 37”这四个字在当时的分量。2016 年 3 月AlphaGo 与李世石的五番棋进行到第二局AlphaGo 在第 37 手落下一子。电视解说和职业棋手普遍陷入困惑这手棋不在人类常规棋谱里甚至一度被看作“失误”。可随着棋局推进这手棋却成为改变棋局走向的关键。多年后回看我们真正该在意的不是那一颗棋子而是它背后的信号AI 第一次在人类最复杂的智力游戏里做出了一手人类顶尖棋手不会选择、但被证明正确的决策。它没有模仿人类而是在搜索与学习中找到了自己的路。今天的开发者看完这段历史可能会觉得有些遥远。但只要打开代码编辑器看到 AI 补全代码打开业务系统看到 AI 自动生成文案、做客服、写 SQL再看到 AI Agent 可以自己调用工具、完成任务你会发现Move 37 代表的“AI 做出了人类没想到的更好选择”已经悄悄发生在软件工程的每个角落。本文不打算做概念考古而是想从 Move 37 切入聊清楚 AI 工程化为什么突然加速以及普通开发者怎么跟上这轮变化。文章里会包含一套可运行的 AI Agent 最小示例以及从 Demo 到生产需要重点关注的工程问题。1. Move 37 的含义AI 不再只是复读人类经验1.1 什么是 Move 37Move 37 指的是 2016 年 AlphaGo 与李世石第二局比赛中AlphaGo 下出的第 37 手。这一手最大的特点是它不在人类棋手熟悉的定式和棋感范围内。当时不少职业棋手看到这手棋的第一反应是“AI 是不是出 bug 了”但随着棋局推进大家才意识到 AlphaGo 正在用一种不同于人类的全局视角控制局面。这手棋之所以被反复提起是因为它打破了“AI 只是在模仿人类”的认知。AlphaGo 的训练资料确实来自人类棋谱但在自我对弈和强化学习之后它有能力生成训练样本之外的全新下法。换句话说AI 给出的答案是“搜索出来的”不是“背出来的”。1.2 为什么它成为 AI 改变一切的标志在 Move 37 之前大众对 AI 的主流印象是“能做分类、能识别图片、能帮你推荐商品”。这些能力本质上属于模式识别AI 的决策边界通常是人类定义的。Move 37 之后公众第一次看到AI 可以在一个规则复杂、可选动作极多的场景里自己找到人类没有走过的解法。这个变化的意义是结构性的。过去人类负责制定规则和策略机器负责在规则内做计算Move 37 则说明某些场景下机器生成的策略本身就可能超过人类经验。随后几年大模型把这种“超人类生成能力”从围棋扩展到了语言、代码、图像、语音和业务流程于是“AI 改变一切”才从口号变成了现实。1.3 开发者视角我们面对的不再是纯粹的工具对开发者来说Move 37 带来的真正冲击是AI 不再只是一个“可预测的函数”而是一个“可能给出非预期答案的系统”。调用模型时同样的输入不一定得到同样输出模型可能给出超出你预期的工具调用也可能在某些边界情况下产生幻觉。因此AI 应用开发的方法论也变了。传统开发讲究“输入-逻辑-输出”的确定性AI 工程则更接近于“约束-评估-迭代”。我们的任务不是保证程序永远走同一条路而是设计好边界、工具、反馈和兜底让 AI 在合理范围内自由发挥。这就是所谓的 AI 工程实践。2. 从 Move 37 到 GPT 时代AI 工程化的三条主线2.1 模型能力从专用智能到通用生成AlphaGo 是专用智能它只做围棋。大模型时代模型开始统一处理文本、代码、图片和语音。以 GPT 为代表的大语言模型把“下一个词预测”做到了足够大之后涌现出了理解、推理、代码生成、角色扮演等通用能力。对工程人员来说这意味着 AI 不再是某个业务模块里的附属功能而可以成为整个系统的“大脑”。你不需要为每个场景单独训练模型而是通过提示词、工具调用和上下文管理让同一个模型适配不同场景。2.2 交付形态从训练实验到部署服务2016 年做 AI 应用的门槛很高需要数据、算力、算法团队训练和部署周期很长。现在主流大模型厂商都提供 API开发者只需要几十行代码就能把一个模型集成到业务系统里。这带来了新的工程问题模型 API 的稳定性、延迟、成本、限流、版本更新都需要纳入系统设计。模型部署也从“物理机 GPU 训练集群”变成了“API 网关 模型服务 缓存降级”的现代服务架构。很多团队开始把“模型即依赖”当作基础设施来看待因为模型 API 和数据库、消息队列一样会故障、会超时、会升级。2.3 应用形态从聊天窗口到 Agent 工作流聊天机器人只是大模型应用的起点。现在更受关注的是 AI Agent也就是让模型自主理解目标、拆解任务、调用工具、检查结果并在多轮迭代中完成任务。这个思路本质上和 Move 37 一脉相承模型不只是在“回答”而是在“行动”。AI Agent 的工程化难点在于如何让模型稳定调用工具如何处理工具返回的异常数据如何设置最大轮数防止死循环如何记录完整执行链路用于追溯。这些问题无法靠“多写几句提示词”治愈必须靠工程架构解决。3. “突然发生在每个地方”AI 正在改变软件工程3.1 AI 编程助手融入日常开发最近几年AI 编程助手已经成了许多开发者的标配。补全代码、生成单测、解释报错、重构函数这些原本需要查文档和搜索的操作现在可以在编辑器里直接完成。像 Cursor 这类 AI 原生编辑器甚至把“和 AI 对话改代码”变成了核心交互方式。AI 编程的普及带来了一个明显变化开发者的核心能力从“记住语法”变成“描述问题、审阅代码、验证结果”。你不需要知道每一个库的完整 API但你需要有能力判断 AI 生成的代码是不是正确、安全、可维护。这个过程很像 Move 37 的隐喻AI 提出建议人类负责判断和兜底。3.2 AI Agent 正在成为新的应用范式如果说 AI 编程改变了开发者自己的工作效率那么 AI Agent 正在改变业务系统的构建方式。客服机器人可以查订单、退款、回答问题运营助理可以自动生成排期、发送报表数据分析助手可以读取数据库、生成图表、解读趋势。这些系统的共同点是模型负责理解和规划外部 API 和内部服务负责执行。为了让 Agent 可靠运行我们需要制定工具协议、权限边界、审计日志、人工审批等机制。这已经不是“自然语言处理”问题而是完整的后端工程问题。3.3 企业对 AI 人才的需求变化随着 AI 从“演示品”进入生产环境企业对人才的需求也从“算法研究员”扩展到了“AI 应用开发工程师”“AI 产品经理”“大模型部署工程师”。相比从零训练模型市场更稀缺的是能快速把模型接入业务、控制成本、保障稳定性的人才。这意味着即使你不研究算法也可以进入 AI 领域。掌握 Python、Restful API、数据库、容器化部署再理解提示词、上下文管理、RAG、Agent 工具调用就足以胜任大量 AI 工程岗位。后续第 6 节会给出一个相对清晰的学习路线。4. 复刻一次“Move 37”AI Agent 最小工程示例4.1 场景设计为了让你直观感受“模型自主决策”的工程流程这一节实现一个非常小的 AI Agent。用户发出一个混合请求模型根据请求内容自行决定调用哪些工具然后工具返回结果模型基于结果继续回答。这里的核心不是聊天而是“模型在循环里做决策”。这和 AlphaGo 不断搜索、评估、落子有相似之处模型不是一次性给出答案而是走一步、看结果、再走一步。具体场景如下用户问帮我计算 5 个单价 39.9 的商品折扣 10 元总价是多少另外看看咖啡的市场趋势给我一个定价建议。模型需要调用calculate_order_total计算订单总额。模型需要调用get_market_trend获取商品趋势。最后把结果组织成自然语言回复。4.2 环境准备示例使用 OpenAI Python SDK 的兼容调用方式。如果你使用的是其他大模型平台只需更换base_url、api_key和model即可。建议环境Python 3.9 及以上版本。安装openai库。准备一个大模型 API Key并确保运行环境可以访问对应的 API 服务。安装命令如下pip install openai如果你的项目会读取.env文件还需要安装python-dotenvpip install python-dotenv4.3 第 1 步基础模型调用先完成最基础的调用确认环境可以正常工作。# 文件basic_call.py import os from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), ) resp client.chat.completions.create( modelos.getenv(OPENAI_MODEL, gpt-4o-mini), messages[ {role: user, content: 你好请用一句话介绍 Move 37。} ], ) print(resp.choices[0].message.content)运行前设置环境变量。这里用OPENAI_API_KEY举例实际密钥请通过安全渠道配置。export OPENAI_API_KEY你的 API Key export OPENAI_MODELgpt-4o-mini python basic_call.py如果网络和鉴权正常你会看到模型输出一段关于 Move 37 的简介。这一步主要验证 SDK 版本、模型名称和 API Key 配置是否正确。4.4 第 2 步定义工具和模型可识别的工具清单要让模型“学会”调用工具需要给模型提供 JSON Schema 形式的工具描述。下面的代码定义了两个工具一个是计算订单总金额另一个是返回咖啡商品的市场趋势。# 文件tools.py import json def calculate_order_total(unit_price: float, quantity: int, discount: float 0.0) - dict: total unit_price * quantity - discount if total 0: total 0.0 return { total: round(total, 2), currency: CNY, } def get_market_trend(product_name: str) - dict: trends { 咖啡: {trend: 上升, suggestion: 可以小幅提价}, 手机壳: {trend: 平稳, suggestion: 保持现价}, } return trends.get( product_name, {trend: 未知, suggestion: 建议先做小范围测试}, ) TOOLS [ { type: function, function: { name: calculate_order_total, description: 计算订单总金额支持折扣, parameters: { type: object, properties: { unit_price: {type: number, description: 商品单价}, quantity: {type: integer, description: 商品数量}, discount: {type: number, description: 折扣金额}, }, required: [unit_price, quantity], }, }, }, { type: function, function: { name: get_market_trend, description: 查询指定商品的市场趋势和定价建议, parameters: { type: object, properties: { product_name: {type: string, description: 商品名称}, }, required: [product_name], }, }, }, ]关键是tools数组里的parameters必须使用严格的 JSON Schema。模型会从描述中理解参数含义所以描述要尽量精确避免让模型传错字段。4.5 第 3 步实现 Agent 循环下面的代码实现了完整的 Agent 循环把用户消息发给模型如果模型返回tool_calls就依次执行工具并把结果回传给模型如果没有tool_calls说明模型已经准备回答直接返回文字。# 文件agent_demo.py import json import os from openai import OpenAI from tools import TOOLS, calculate_order_total, get_market_trend client OpenAI( api_keyos.getenv(OPENAI_API_KEY), ) TOOL_MAP { calculate_order_total: calculate_order_total, get_market_trend: get_market_trend, } def run_agent(user_message: str, max_rounds: int 3) - str: messages [ {role: user, content: user_message}, ] for _ in range(max_rounds): response client.chat.completions.create( modelos.getenv(OPENAI_MODEL, gpt-4o-mini), messagesmessages, toolsTOOLS, ) message response.choices[0].message messages.append({ role: assistant, content: message.content, tool_calls: message.tool_calls, }) if not message.tool_calls: return message.content or for tool_call in message.tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments or {}) print(f[工具调用] {fn_name} {fn_args}) if fn_name not in TOOL_MAP: result {error: f未知工具: {fn_name}} else: result TOOL_MAP[fn_name](**fn_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse), }) return 达到最大轮次强制结束 if __name__ __main__: question 帮我计算 5 个单价 39.9 的商品折扣 10 元总价是多少另外看看咖啡的市场趋势给我一个定价建议。 answer run_agent(question) print(模型回答, answer)这个循环里有几个工程上的关键点每次把message.tool_calls原样追加到messages这是模型多轮工具调用能够衔接的前提。tool_call_id必须和模型返回的 ID 保持一致否则 API 会校验失败。工具执行要加异常捕获。示例为了简洁没有完整捕获生产环境必须把每个工具的异常转成结构化结果。max_rounds必须有限制防止模型陷入“反复调用工具”的循环。4.6 运行验证运行前设置好环境变量然后执行export OPENAI_API_KEY你的 API Key export OPENAI_MODELgpt-4o-mini python agent_demo.py预期会看到类似下面的输出[工具调用] calculate_order_total {unit_price: 39.9, quantity: 5, discount: 10.0} [工具调用] get_market_trend {product_name: 咖啡} 模型回答订单总价为 189.5 元。咖啡市场趋势为上升建议可以小幅提价。实际输出会因为模型行为和 API 版本不同而略有差异。只要模型识别出需要调用两个工具并且最终返回正确的合计金额就说明 Agent 循环已经跑通。5. 从 Demo 到生产AI 工程实践与模型部署建议5.1 配置管理不要硬编码 API Key在 Demo 里API Key 直接放在环境变量中还可以接受生产环境则必须纳入统一配置管理。常见的做法是使用.env文件存储敏感配置并把.env加入.gitignore同时由配置中心或环境变量注入密钥。下面是一个参考配置模板OPENAI_API_KEYsk-xxxxxxxx OPENAI_MODELgpt-4o-mini OPENAI_BASE_URLhttps://api.openai.com/v1 REQUEST_TIMEOUT60 AGENT_MAX_ROUNDS5使用python-dotenv加载配置import os from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), timeoutfloat(os.getenv(REQUEST_TIMEOUT, 60)), )注意base_url和model会因为平台不同而变化不要在一个系统里写死。模型名称变更时最好通过配置系统动态调整避免改代码发版。5.2 调用容错超时、重试、降级模型 API 和数据库一样可能出现网络抖动、限流和超时。生产环境需要做三层防护设置超时时间默认 60 秒可能太长流式接口和普通接口要使用不同超时策略。重试机制对网络错误和 5xx 错误做有限重试不要无限重试。降级方案当模型不可用时返回兜底回复或切换到备用模型。简单重试示例import time def call_with_retry(create_fn, max_retries3): for attempt in range(max_retries): try: return create_fn() except Exception as exc: if attempt max_retries - 1: raise print(f调用失败准备重试{exc}) time.sleep(2 ** attempt)重试时要小心“模型已经执行了工具”的状态。如果 Agent 流程中第一次工具调用成功但返回结果时网络失败直接重试可能导致重复扣费或重复操作。因此幂等性设计非常重要。5.3 Token 成本与上下文管理大模型应用的成本主要来自 Token。Messages 越长每次请求消耗越大响应越慢。常见的上下文管理策略有只保留最近 N 轮对话。超长历史自动摘要用摘要代替全部原文。工具返回结果太长时先做截断或汇总。对用户输入做长度限制防止超大请求打爆上下文。工程上还需要记录每次调用的 usage 字段。不同平台返回结构不太一样但通常包含prompt_tokens、completion_tokens和total_tokens。这些数据可以用来做成本监控和报警。5.4 模型幻觉与安全边界Move 37 给我们的启示之一是 AI 可能给出“超出预期”的答案。但这里有两面性好的时候是创造坏的时候就是幻觉。当模型不确认数据时它会一本正经地编造内容。生产环境必须通过工程手段降低幻觉影响涉及事实数据时优先通过工具从数据库或接口获取不让模型凭空回答。对模型输出做格式校验例如要求返回 JSON 后必须json.loads成功。对高风险动作比如删除、转账、发布增加人工审批环节。对用户输入做敏感信息过滤对模型输出做脱敏处理。权限设计也要遵循最小权限原则。Agent 不应该直接拿到数据库账号而应该通过一个受限 API 层执行查询。这样即使提示词被恶意注入攻击者也只能操作 Agent 暴露出来的能力而不是整个后端系统。5.5 容器化部署示例当应用规模变大后建议使用容器化部署。下面是一个简单的 Dockerfile 模板实际项目需要根据框架和依赖调整。FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [uvicorn, app.main:app, --host, 0.0.0.0, --port, 8000]如果项目是 FastAPI 服务可以参考下面的目录结构app/ ├── main.py ├── config.py ├── agent.py ├── tools.py └── requirements.txt部署到云平台或 Kubernetes 时还需要配置健康检查、存活探针、日志采集和水平扩缩容。模型 API 调用属于外部依赖应该和数据库、缓存一样纳入依赖监控。6. AI 应用开发学习路线6.1 五个阶段如果你希望系统掌握 AI 应用开发可以把学习路径分为五个阶段提示词工程学会设计高质量的提示词理解温度、系统角色、少样本示例对输出的影响。API 应用开发掌握大模型 API 的调用方式完成聊天、文本分类、信息抽取等基础应用。上下文工程学习向量化、嵌入、向量数据库、RAG 检索增强生成解决私有知识库问题。Agent 开发学习工具调用、任务规划、状态管理、多步骤执行构建能完成实际任务的 Agent。模型部署与运维了解模型微调、量化、推理服务、评估和监控把 AI 应用稳定跑在生产环境。6.2 每个阶段要掌握的技能提示词阶段重点掌握角色设定、思维链、输出格式限定。API 阶段重点掌握流式输出、超时重试、Token 计算。RAG 阶段重点掌握文本切分、向量索引、召回排序。Agent 阶段重点掌握工具协议、异常恢复、审计日志。部署阶段重点掌握容器化、网关、限流、灰度发布和模型评估。编程语言方面Python 是目前 AI 工程最常用的语言但如果你更熟悉 Java、Go同样可以开发 AI 应用。关键不在于语言而在于你是否理解大模型 API 的请求响应模型、工具调用协议和业务系统的集成方式。6.3 推荐练手项目每个阶段都要配合项目做一个“会议纪要助手”上传录音转文字用模型总结待办事项。做一个“客服知识库问答”用 RAG 让模型基于内部文档回答问题。做一个“数据分析 Agent”让模型调用 SQL 接口查询数据库再把结果转成图表。做一个“自动化工单系统”让 Agent 根据用户描述调用不同处理流程。这些项目不需要一开始就做到生产级关键是完整跑通“输入-模型-工具-反馈-输出”的链条。每做一个项目都要思考哪些环节可能出错如何通过日志和评估发现错误这些问题才是 AI 工程实践的核心。7. 常见问题与排查思路AI 工程和传统后端一样会遇到各种环境问题、数据问题和稳定性问题。下面整理了几个高频场景。问题现象可能原因排查思路请求报 401 鉴权失败API Key 没有配置或配置错误检查环境变量是否注入密钥是否有空格平台权限是否开启提示超出上下文长度历史消息或工具结果过长截断历史、压缩工具结果、升级支持更长上下文的模型模型返回格式不稳定输出没有严格约束要求模型返回 JSON并在代码中做二次校验和后处理工具调用解析失败模型返回的arguments不是合法 JSON增加异常捕获让模型重新生成参数Agent 死循环工具一直返回可再次触发工具的内容设置最大轮数检测重复调用加入人工中断开关网络超时模型 API 响应慢或网络抖动设置超时时间增加重试和降级策略模型输出幻觉模型不知道事实却强行回答把知识来源切换到 RAG 或工具查询禁止模型猜测生产成本过高上下文太长或并发太多使用缓存、降低输出长度、批量处理、按业务拆分模型排查 AI 问题时最重要的一步是“把不可见变成可见”。每次请求都要记录用户输入、模型原始输出、工具调用参数、工具返回结果、最终回答、耗时和 Token 用量。有了这些日志大部分问题都可以通过回放找到原因。8. 结语做出你自己的第 37 手Move 37 的珍贵之处不在于那一步棋本身而在于它展示了 AI 生成“非人类经验”的可能性。现在这种可能性已经不再局限于围棋棋盘而是进入了每一行代码、每一个业务系统、每一份文档里。作为开发者我们能做的不是等一个全知全能的 AI 产品出现而是把业务问题拆成可验证的子问题给 AI 设定边界通过工程手段不断评估和迭代。也许你的下一个实验就会做出自己的“第 37 手”一个超出常规文档之外但被真实数据证明有效的 AI 功能。如果你准备动手可以从今天开始写一个最简单的模型调用给它一个工具让它在循环里完成一个小任务。别只停留在看教程AI 工程最需要的是亲手跑通一次“模型决策-工具执行-结果反馈”的完整链路。