从Move 37到AI Agent：大模型应用开发与工程化落地实践

2016年3月AlphaGo 与李世石的第四盘棋第37手落下时几乎所有讲解围棋的人都说“看不懂”。传统的棋理、定式、经验在这一步面前全部失效。然而事后回看正是这一步让 AlphaGo 彻底掌控了那一盘的局面也第一次让真实世界看到AI 不是只会记住人类教给它的答案它能在没有标准答案的领域里自己走出一条路来。近十年过去Move 37 正在从棋盘上扩散到每一个和“决策”有关的地方。现在的 AI不再只是下棋它能写代码、读文档、调接口、分析日志、参与产品设计甚至在企业的业务流程里独立完成某些环节。它不再是一个演示视频里的“惊叹点”而是普通开发者每天都会打开的工具是应用后端的一个模块是生产环境里的一个服务。这篇文章想用开发者的视角把从 Move 37 到今天 AI 工程化落地之间的变化拆开讲清楚。我们会先理解 Move 37 为什么重要再看它背后的能力如何演变成现在的 AI Agent、RAG、提示词工程最后落到实践上一个最小可复用的 Agent 代码、一个检索增强示例、一套可执行的评估方法以及生产环境里最重要的权限、成本和回滚问题。1. Move 37 到底意味着什么AI 第一次走出人类经验1.1 这步棋为什么让人类棋手震惊围棋是一个复杂度极高的博弈游戏历史上人类棋手经过几千年积累了大量被反复验证的定式和棋理。AlphaGo 和李世石对阵之前主流观点仍然是“AI 至少还需要十年才能挑战顶尖棋手”。因为围棋的可能局面数量远超国际象棋传统的暴力搜索根本不可行。第 37 手是一步看起来“不合常理”的下法。它放弃了局部最明显的争夺转而在更宏观的位置落子。按当时人类棋手的理解这步棋局部有损失后续也未必能直接形成进攻。但它真正的价值在于改变了整盘棋的“势”让 AlphaGo 后续的战略推进变得极其顺畅。这里面最关键的并不是“AI 赢了”而是 AI 提出了一种人类经验之外的新解。它证明了一个重要问题当模型在海量对局中训练到足够充分的程度它的决策质量有机会超过“由人类经验总结出的最优解”。这就是 Move 37 的真实含义——AI 第一次走出人类经验的边界。1.2 从技术和机制上理解这步棋早期围棋程序靠的是人工编写规则和搜索算法它们无法应对围棋庞大的分支。AlphaGo 的做法完全不同它用深度卷积神经网络分别学习“当前局面下哪里值得下”和“当前局面谁更有利”再用蒙特卡洛树搜索把两者结合让搜索过程只沿着最有希望的路径展开。这个结构放到今天的 AI 应用里会发现惊人的相似性策略网络相当于现在大模型里的“生成能力”负责提出候选动作。值网络相当于“评估能力”负责判断这个候选动作值不值得继续。蒙特卡洛树搜索相当于“规划与验证”让 AI 不止是猜一个答案而是在多个可能性里推演并选择更稳定的那一条。当时我们很难想象这套机制能迁移到软件工程里。现在再看代码补全、AI Agent 的工具调用、RAG 的检索重排本质上都在做同一件事先生成多个候选再评估它们的价值最后选一个执行。这和 AlphaGo 的下棋逻辑是一脉相承的。1.3 Move 37 的真正遗产是“决策能力”很多人把 AlphaGo 的成就归结为“算力强”这是个误解。计算力只是一个基础条件真正的突破来自训练方式让模型自己从数据里总结规律而不是由人类把规则写死。Move 37 的遗产是让整个行业意识到AI 的核心价值不在于它能记住多少人类知识而在于它能生成“人类可能不会想到但客观有效”的方案。过去这只能在围棋这样规则封闭的领域实现因为局面可以清晰评估输赢有明确标准。而今天代码的正确性、业务流程的效率、用户转化的提升正在成为新的“评估函数”。AI 的方案不再需要是人类熟悉的方案只要最终指标变好它就是有价值的。2. 从棋盘到代码AI 正在成为软件工程的基础设施2.1 开发者的工作方式已经被重写过去几年里AI 在软件工程领域的落地速度远超大多数人的预期。最早是代码补全工具在一个函数里自动提示下一行后来是代码生成用自然语言写需求AI 直接给出完整模块再往后是 AI 代码评审、自动化测试生成、Bug 定位、文档转换、数据库查询优化。对这些工具我个人的判断是它们真正降低的不是“打字成本”而是“从想法到代码之间的翻译成本”。一个后端开发者以前要先把需求拆成接口设计、数据库表结构、业务逻辑、异常处理再逐行实现。现在可以把需求描述清楚让 AI 生成初版然后再去审查、修正、补充边界情况。这就意味着一个工程师能承担的工作范围变大了。热搜词里出现大量“AI 编程”“Cursor AI 编程”“AI Agent 开发”这背后并不是炒作而是真实的工程变化。GitHub Copilot、Cursor 这类工具已经不再只是“高级自动补全”它们能跨文件理解项目结构能根据 issue 修改代码能在测试失败后自己调整实现。如果你还没把这些工具纳入日常开发流程那在第一层就已经落后了。2.2 软件工程师的核心竞争力正在迁移如果 AI 能完成越来越多“写代码”的工作那工程师的价值在哪里我的答案是定义问题和判断结果的能力。过去写代码本身就是核心技能因为从需求到实现的路径很长需要大量专业知识。现在AI 承担了实现层的很大一部分人类的价值逐渐集中在能不能把模糊的业务需求拆解成 AI 能理解的清晰任务。能不能判断 AI 生成的代码是否满足性能和安全要求。能不能设计一套验证机制在 AI 输出可能出错的前提下保证系统依然可靠。这和 AlphaGo 的“教练”角色很像。教练不需要亲自落子但他要能读懂 AI 的意图判断哪一步走得好哪一步有风险然后在战略层面做决策。2.3 对团队协作方式的直接影响AI 进入工程流程后最明显的变化是代码审查成为更重要的环节。以前审查代码主要是查逻辑错误、风格问题和潜在 Bug现在还需要审查“这段 AI 生成的代码有没有引入未预期的依赖、有没有泄露内部逻辑、有没有做足输入校验”。团队里开始出现新的角色分工。有人专门负责维护提示词模板有人负责搭建评估集有人负责 Agent 工具链的权限管控。这些在今天看起来还是少数团队的配置但会逐步变成软件工程团队的基础设施。3. AI Agent从“聊天”到“做事”的关键一步3.1 什么是 AI Agent先说结论AI Agent 是“能够自主执行任务的大模型应用”。它和普通聊天机器人的区别不在于模型本身而在于它被赋予的工具和行动边界。一个聊天机器人只能生成文本你说一句它回一句。AI Agent 则可以做更多事查数据库、调接口、发消息、写文件、执行命令甚至在一个流程里连续做多步操作直到完成任务。要拆开看Agent 通常包含四个部分大模型负责理解任务、生成决策。工具集合包括函数调用、API、数据库查询、文件操作等。记忆短期记忆保存当前任务上下文长期记忆保存用户偏好和历史结果。行动循环不断重复“理解、决策、执行、观察结果、再决策”的过程。这套结构和人类处理复杂任务的思路是一致的。你接到一个“把订单报表发到群里”的任务不会只做一步而是先查数据再整理格式再发送最后确认是否成功。Agent 就是把这种多步操作自动化。3.2 从 Chatbot 到 Agent 的差别很多人以为给聊天机器人加一个插件就是 Agent这是不准确的。它们的核心差异在“自主程度”。Chatbot 是一问一答每一步都由用户驱动。Agent 则有一个目标可能在执行过程中自己决定先调用哪个工具、如何处理异常、是否需要重试。这个“自主判断”的能力让 Agent 能完成更复杂的任务同时也带来了新的风险你无法完全预测它每一步会做什么。所以生产环境里的 Agent必须配权限控制、审计日志和人审环节。3.3 为什么现在 Agent 才被大范围讨论Agent 的概念其实很早就有了但过去受限于模型能力效果不好。最早的做法是用规则引擎写死任务流程复杂场景几乎无法维护。现在的变化在于大模型拥有了更强的意图理解、推理和工具调用能力Agent 才真正从一个“玩具”变成“工程组件”。热搜词里“AI Agent开发”持续出现背后是真实需求企业级的 AI 应用不满足于“问一句答一句”而是要解决实际业务问题。比如自动化运维、智能客服工单处理、代码仓库管理、数据分析报告生成这些任务天然是多步骤的只有 Agent 形态才能完成。4. AI 应用开发真正要过的关评估与治理4.1 最大的问题不是“模型不够聪明”而是“不知道好不好用”开发 AI 应用时很多人第一个想法是“找最强的模型”。但实际工程里最大的瓶颈往往不是模型能力而是缺乏一套可靠的评估机制。传统软件工程里功能对不对可以用测试用例判断。AI 应用不一样同一个问题模型今天答得好明天升级版本后可能就答偏了同一个模型换一种提问方式结果差异也很大。如果没有评估集你根本不知道一次改动是变好了还是变坏了。4.2 评估集怎么建一个合格的 AI 应用评估集至少应该覆盖三类样本典型场景覆盖 80% 的正常问题确保基本能力不退化。边界情况包括空输入、超长输入、含糊问题、多轮对话中的歧义确保模型不会崩溃。高风险场景比如涉及删除操作、资金操作、权限变更的对话确保模型不会给出危险建议。每一条样本除了输入还要有预期结果和质量标准。质量标准不一定是标准答案也可以是“必须包含哪些关键要素”“是否拒绝执行禁止操作”“回复是否简洁明确”。4.3 没有评估就没有迭代如果团队准备把 AI 应用放到生产环境我建议从第一天就开始积累评估样本。每次线上用户反馈问题都可以转成一条回归用例。这样模型版本升级、提示词修改、RAG 召回策略调整都有了可对照的基准。另外不要只看模型自己的回答质量还要看端到端的效果。比如一个客服 Agent最终指标是“工单解决率”而不是“回答通顺度”。模型回答得很流畅但如果没解决用户问题这个流程就是失败的。5. 一个可落地的最小 Agent 示例5.1 核心思路ReAct 循环我们用一个最小示例来理解 Agent 的工作方式。它的核心叫 ReAct也就是“思考 行动”的循环模型先思考当前该做什么然后调用工具观察返回值再决定下一步做什么。循环反复进行直到模型认为任务已经完成。下面这个示例我会用 Python 实现一个极简的 Agent 调度器它能识别用户问题、选择工具、执行并返回结果。为了防止读者被某个 SDK 绑定我会把大模型调用封装成一个函数你可以替换成任何自己使用的模型服务。5.2 定义工具集与系统提示词# 文件react_agent_demo.py import json def search_qa(query: str) - str: 模拟内部知识检索工具 doc_db { 订单超时时间: 订单默认超时时间为30秒可在 config/order.yaml 中修改。, 发布计划: v3.0 计划在 2026 年 Q3 发布。, 数据库连接池: 连接池默认上限为20生产环境建议根据压测结果调整。 } return doc_db.get(query, 未检索到相关知识) def execute_sql(sql: str) - str: 模拟只读 SQL 查询工具 if not sql.strip().upper().startswith(SELECT): return 仅允许执行 SELECT 查询 return 模拟查询完成返回 42 行结果 TOOLS { search_qa: search_qa, execute_sql: execute_sql, } SYSTEM_PROMPT 你是一个运维助手。请你根据用户问题按以下格式输出 JSON { thought: 你对当前任务的思考, action: 要调用的工具名如果不需要调用工具则填 none, action_input: 工具的入参, answer: 如果你认为任务已完成这里填最终回答否则留空 } 可用工具search_qa, execute_sql 注意json 中只能包含以上字段不要额外输出文字。系统提示词里我刻意要求模型输出 JSON这样调度器可以稳定解析结果。这比直接让模型输出自由文本更可靠也是生产环境里常用的做法用结构化输出约束模型行为。5.3 实现大模型调用为了让读者能真正跑通我这里使用通用的 HTTP 调用方式兼容大多数提供 Chat 接口的服务。# 文件llm_client.py import os import requests def call_llm(messages, modelgpt-4o-mini): 调用 Chat 兼容接口。 请通过环境变量设置 LLM_API_KEY 和 LLM_BASE_URL。 base_url 示例https://api.openai.com/v1 api_key os.getenv(LLM_API_KEY) base_url os.getenv(LLM_BASE_URL, https://api.openai.com/v1) payload { model: model, messages: messages, temperature: 0.2, response_format: {type: json_object} } resp requests.post( f{base_url}/chat/completions, headers{Authorization: fBearer {api_key}}, jsonpayload, timeout30 ) resp.raise_for_status() return resp.json()[choices][0][message][content]如果你使用的是本地部署模型或国内大模型服务通常只需要修改环境变量LLM_BASE_URL和LLM_API_KEY请求格式基本兼容。这里强调一个工程原则不要把 API Key 硬编码在代码里一律通过环境变量或配置中心读取。5.4 实现 Agent 主循环# 文件react_agent_demo.py def main(): user_input 订单模块的超时时间是多少 messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input} ] for step in range(4): content call_llm(messages) data json.loads(content) print(f[Step {step 1}] 思考{data.get(thought)}) action data.get(action, none) if action ! none: tool_func TOOLS.get(action) if tool_func: result tool_func(data.get(action_input, )) print(f[Step {step 1}] 调用 {action}返回{result}) messages.append({ role: user, content: json.dumps({tool_result: result}, ensure_asciiFalse) }) continue print(f[完成] {data.get(answer)}) break else: print([失败] 达到最大循环次数任务可能未完成) if __name__ __main__: main()这个主循环里有三个值得注意的地方第一设置了最大循环次数。生产环境里Agent 如果陷入死循环会浪费大量 token 和接口调用资源必须设置上限。第二把工具返回结果追加到 messages 里让模型在下一次生成时能看到工具的返回值。这是 ReAct 循环的关键模型必须“看到结果”才能继续决策。第三每一步都打印日志。这在调试阶段非常重要因为 Agent 出错时你至少要能看出它是在哪一步做错了决策。运行方式export LLM_API_KEY你的APIKey export LLM_BASE_URLhttps://api.openai.com/v1 python react_agent_demo.py预期结果是模型先查找search_qa工具检索“订单超时时间”相关内容然后输出最终答案。如果失败优先检查 API Key 是否正确、网络是否能连通模型服务、返回内容是否能被json.loads解析。6. RAG 与提示词工程企业落地的主干技术6.1 为什么大多数企业场景需要 RAG大模型的训练数据有截止时间它无法知道你公司内部的接口文档、业务规则、故障记录。如果直接让模型回答内部问题它大概率会编造答案。RAGRetrieval-Augmented Generation就是为了解决这个问题。RAG 的基本流程是先把企业文档切分成块建立索引用户提问时先从索引里检索出最相关的文档片段再把“用户问题 文档片段”一起拼进提示词让模型基于给定资料回答。这个过程的好处是不需要重新训练模型只要更新文档库模型就能回答新问题。对于绝大多数企业来说RAG 比微调更实际、成本更低、更新更及时。6.2 一个简单可复现的 RAG 检索示例先说明下面这个示例我故意没有引入向量数据库而是用字符级倒排索引做演示目的是让你看清 RAG 的完整流程。生产环境建议用 Elasticsearch、Milvus 或专门向量数据库。# 文件simple_rag.py from typing import List def chunk_text(text: str, size: int 150, overlap: int 20) - List[str]: 按固定字符长度切分文本保留重叠避免切断语义。 chunks [] start 0 while start len(text): end min(start size, len(text)) chunks.append(text[start:end]) if end len(text): break start end - overlap return chunks def build_char_index(chunks: List[str]): 最简单的字符倒排索引记录每个字符出现在哪些 chunk 中。 index {} for idx, chunk in enumerate(chunks): for ch in set(chunk): index.setdefault(ch, set()).add(idx) return index def retrieve(query: str, index: dict, chunks: List[str], top_k: int 2) - List[str]: 根据字符命中数量排序返回最相关的 top_k 个片段。 query_chars set(query) scores [] for idx, chunk in enumerate(chunks): hit len(query_chars index.get(idx, set())) if hit 0: scores.append((hit, idx)) scores.sort(reverseTrue) return [chunks[idx] for _, idx in scores[:top_k]] if __name__ __main__: document ( 订单系统默认超时时间为30秒。用户下单后如果支付回调在30秒内未到达 系统会自动将订单标记为超时。超时订单会在后台任务中被关闭库存会回滚。 生产环境建议根据压测结果调整超时时间。订单模块的配置位于 config/order.yaml。 ) chunks chunk_text(document) index build_char_index(chunks) for c in retrieve(订单超时时间, index, chunks): print(c) print(---)这个示例按字符做索引对中文没有分词依赖能跑通流程。它的问题是精度低同一个字命中次数多但语义可能无关。生产环境替换为向量检索后整体流程依然一致只是“召回”这一步的质量更高。6.3 提示词工程是 RAG 的最后一公里RAG 检索到文档片段后如何组织提示词直接影响回答质量。一个常见的失败模式是检索结果正确但模型被无关片段干扰最后答非所问。所以提示词必须“明确限定信息来源”。一个推荐的模板你是一个技术支持助手。请只根据下面提供的资料回答问题。 如果资料中没有相关信息请直接回答“资料中未找到相关信息”不要自己编造。 资料 {retrieved_chunks} 问题{user_question}同时我会在提示词里加上稳定性要求不要重复问题内容不要输出思考过程回答控制在 200 字以内。这些细节看起来简单但在真实场景里能明显减少“正确但啰嗦”和“自信但错误”的输出。很多团队一开始把 RAG 的难点放在召回率上实际排查多了以后会发现提示词导致的“串味”才是最频繁的问题。检索到的多个片段之间如果有冲突模型往往会选择后出现的那个或者把两个片段的内容混在一起。解决方式有两种一是调整检索数量减少干扰片段二是在提示词里明确“如果资料之间存在冲突请指出冲突并选择证据更充分的那一个”。7. 生产环境避坑指南权限、成本、回滚7.1 AI Agent 的权限设计要遵循最小化原则AI Agent 能自己做决定这在带来便利的同时也带来风险。如果一个 Agent 拥有完整数据库权限又因为提示词注入被恶意引导后果不堪设想。生产环境里Agent 的工具权限应该做到任何工具只能使用最小权限比如数据库查询只读账号文件操作限定指定目录。危险操作必须有人工审批环节比如批量删除、资金转账、权限变更。所有工具调用必须写入审计日志记录调用时间、入参、返回结果。在正式环境操作前先在小规模测试环境验证并准备备份和回滚方案。如果你在开发内部工具不要觉得“只是内部用就无所谓”很多安全事故就发生在内部工具上。7.2 成本控制Token 是不可忽视的预算维度AI 应用和传统后端不一样每次请求都要消耗 token而 token 是有成本的。Agent 一次任务可能调用模型多次如果循环失控费用会快速累积。常用的控制手段包括设置单次任务的最大模型调用次数。合理控制上下文长度不要把所有历史消息都带进请求。缓存高频请求的答案相同问题直接复用。使用性价比模型处理简单任务强模型只处理复杂分支。从运维视角看AI 应用的监控应该同时关注延迟、可用率和 token 消耗。一个 Agent 任务如果总是需要 10 次模型调用才能完成即使模型本身很快整体体验也会变差。7.3 灰度发布与回滚是硬要求模型升级、提示词修改、检索策略调整都会影响最终输出。每次改动都应该先跑一遍评估集再通过灰度发布逐步放量。灰度期间需要对比新旧版本的业务指标比如用户满意度、工单解决率、代码评审通过率而不是只看模型回答“好不好”。如果新版本表现不如旧版本要能一键回滚。这也意味着模型版本、提示词版本、检索配置都要纳入版本管理不能只覆盖代码库里的一个文件。8. 不同角色的开发者从哪条路径切入 AI8.1 后端开发者从接入模型到编写工具后端开发者最容易上手的路径是设计 Agent 能调用的工具。工具的本质就是函数输入是模型生成的参数输出是结构化结果。这块恰好是后端工程师最擅长的。建议路径先写一个简单的 HTTP 接口供模型调用。再封装一个小型 Agent串联 2 到 3 个接口。关注权限、日志、重试和超时处理。8.2 前端开发者从界面体验到交互创新前端开发者可以从 AI 交互界面的角度切入。传统的表单交互正在被对话式、流式输出、意图预览等新交互取代。前端要做的是让模型输出在界面上“可理解、可纠错、可操作”。8.3 算法工程师从训练模型到建设评估算法工程师的价值不只是训练模型更在于建立评估体系。一个 AI 应用团队最缺的往往是能定义“好”与“坏”的人。算法工程师对数据敏感做评估集、分析失败样本是天然适合的切入点。8.4 测试与运维从手工检查到自动化守护测试工程师可以研究 AI 输出断言为自然语言回答建立自动校验规则。运维工程师可以搭建 AI 应用的可观测体系把 token 消耗、Agent 执行链路纳入监控。这些方向目前都非常缺人。如果你使用的是 Java 技术栈可以关注 Spring AI 这类框架它把模型调用、向量存储、工具调用封装成统一抽象降低了集成成本。如果使用 PythonLangChain 和 LlamaIndex 生态同样值得跟进。但我的建议是不要一开始就扎进框架细节先把手动调用模型、手动写工具、手动拼提示词这条路走一遍理解原理后再用框架提高效率。9. 写在最后Move 37 正在以另一种方式重演Move 37 让我们第一次意识到AI 给出的方案可以违反人类的直觉但仍然正确。今天当你在代码评审时看到 AI 写出的陌生写法在数据分析时看到模型提出一个不符合经验但指标更好的建议在 Agent 执行日志里看到一条你认为“不该走”但结果正确的链路那时的感觉和 2016 年棋手看到第 37 手时是一样的。AI 正在从“模仿人类经验”走向“创造超出人类经验的新方案”而且这个过程已经不再局限于围棋棋盘而是发生在软件工程的每一个角落。对开发者来说最需要转变的不是学会某个工具而是建立一种新的判断体系当 AI 给出一个你没有想过的答案时不急着否定它先去验证它。这恰恰是从 AI 使用者走向 AI 工程师的关键一步。如果你想真正进入这个领域我的建议很直接从今天开始就选一个你日常工作中重复、枯燥、需要查文档的任务把它变成一个 Agent 工具。不要等完美的框架不要等最强的模型先跑通一个最小闭环。这个过程就是你自己的 Move 37。