1. 从代码补全到多智能体协同AI 编程到底进化到哪了这几年 AI 编程的热度一直没降过从最开始大家觉得这东西就是给程序员配了个高级补全插件到现在 Agent、多智能体协同软件工程这类概念满天飞变化快得让人有点措手不及。我身边不少朋友还在纠结 GitHub Copilot 和 Cursor 谁更好用而另一批人已经在用多个 AI Agent 协作干活了。这个跨度说白了就是大家对 AI 编程的认知还停留在代码补全这一层但实际技术演进已经走到了 AI 参与完整软件工程流程的阶段。先说清楚一个概念代码补全解决的是这一行接下来该写什么本质是语言模型根据上下文预测 token它没有任务目标也不知道你为什么要写这段代码。而 Agent 解决的是这个功能怎么实现、需要改哪些文件、怎么验证改对了它有目标、有计划、能调用工具、能根据执行结果纠偏。这两者之间的差距不是版本号从 1.0 跳到 2.0 的区别而是工具和协作者之间的区别。再说到多智能体协同软件工程这个概念听起来高大上但拆开看你就明白了一个 Agent 负责理解需求一个 Agent 负责写代码一个 Agent 负责审查代码一个 Agent 负责跑测试。每个 Agent 各司其职通过消息传递协作共同完成一个软件工程的闭环。这不是科幻主流框架如 LangGraph、AutoGen、CrewAI 都已经提供了成熟的多 Agent 编排能力我在实战营里带学员用这些框架搭建过完整的协作流程效果确实比单 Agent 硬扛要好得多。这篇文章我会从工具选型、Agent 核心设计、多智能体协同机制、实战案例、问题排查这几个维度把我在这条路上趟过的坑、验证过有效的方法、可以直接抄作业的配置都拿出来分享。无论你现在只用过代码补全还是已经在折腾单 Agent这篇文章都能帮你把Agent 工程化这块拼图补完整。2. 工具选型AI 编程工具和 Agent 框架怎么搭配才不踩坑2.1 编辑器和补全插件别在补全上花太多时间纠结先说编辑器层。现在很多人还在纠结 VSCode 代码补全快捷键是什么、哪个补全插件最好用我的建议是把时间省下来因为你真正需要的是一个能理解你项目上下文的 AI 编程环境。VSCode 里 CtrlSpace 触发补全这种基本功当然要会但别沉迷于调参那不是核心竞争力。我用过的补全方案有这么几个梯队第一梯队GitHub Copilot老牌选手训练数据量大对常见模式的补全最稳和 VSCode、JetBrains 系列集成都很成熟。第二梯队通义灵码、Codeium 这类国内免费方案里算能打的胜在不用考虑网络问题中文 prompt 理解也还行。第三梯队各家云厂商自带的 AI 插件质量参差不齐但胜在跟自家云服务、代码托管平台打通得好。如果你只在编辑器里用补全Copilot 或者通义灵码就够了。但问题是补全模式的天花板就在那里——它能帮你写函数但帮你改不了 bug重构不了模块更别提跨文件实现一个功能了。所以我的观点很明确补全工具随便选一个顺手的重点精力放在 Agent 层。2.2 Agent 工具Cursor、Claude Code、Codex 怎么选Agent 层的工具这两年迭代非常快我按类型给你梳理一下类型代表工具特点适合场景编辑器内 AgentCursor对上下文理解强能跨文件编辑Tab 补全和对话式编程一体化日常开发、中小型项目重构命令行 AgentClaude Code、Codex CLI直接在终端里跑权限大能执行命令、读写文件适合自动化流水线批量任务、CI 集成、复杂工程操作IDE 深度集成Cursor VSCode 插件、JetBrains AI与断点调试、测试框架联动需要和 IDE 特性深度绑定的场景我个人的主力方案是 Cursor 写业务代码Claude Code 或者 Codex CLI 跑自动化任务。为什么这么分因为 Cursor 在交互体验上做得最好你选中一段代码它能看到你的光标位置、选区内容、相关文件改起来像有个结对编程的同事在旁边。而命令行 Agent 的优势在于可脚本化、可批处理我可以一次性扔给它十个任务让它自己跑完再汇报。但这里我要泼一盆冷水别迷信谁是最强工具只是载体真正决定产出质量的是你给 Agent 的上下文和任务描述质量。同一个 Agent 框架换个人用效果可能天差地别差别就在 prompt 设计。2.3 Agent 框架LangGraph、AutoGen、CrewAI 的选型逻辑如果你要搭多智能体协同绕不开 Agent 框架这一层。市面上主流的有三个LangGraph、AutoGen、CrewAI。我三个都深度用过说说真实感受。LangGraph 是 LangChain 团队出的核心优势是图结构的状态编排。你可以把多 Agent 的协作流程定义成一张图节点是 Agent 或工具边是状态转移条件每个节点都能读取和修改共享状态。这种设计特别适合流程明确、分支复杂的工程场景比如先做代码审查审查不通过就回到编码节点重写通过就进入测试节点。可控性非常好排查问题的时候你能清楚知道系统卡在哪个节点。AutoGen 是微软出的核心思想是对话驱动的多 Agent 协作。你定义几个 Agent设置好它们各自的 system prompt然后让它们互相发消息就像拉了个群让几个专家互相辩论。适合探索性问题比如架构方案对比、代码 review 讨论但问题是你很难精确控制对话走向容易被带偏。CrewAI 走的是角色扮演路线把每个 Agent 定义成带角色、目标、背景故事的成员然后编排任务流程。上手最快概念最直观适合快速原型验证。但说实话复杂的工程场景下它的控制力不如 LangGraph。我的建议是单 Agent 或者简单多 Agent 场景用 CrewAI 快速出活生产级别的多智能体协同直接学 LangGraph别犹豫。AutoGen 适合做研究和实验落地到工程项目里你会发现状态不可控这件事很头疼。3. Agent 工程化的三大核心Prompt、记忆、工具3.1 Prompt 工程从请你写个函数到岗位说明书很多人用 AI 编程效果不好问题出在把 Agent 当搜索引擎用——给一句需求就等结果结果不满意就说AI 不行。其实在 Agent 工程化里Prompt 已经不再是简单的指令它更像是你给一个新入职的工程师写的岗位说明书。我总结了一套实战中特别好用的 prompt 写法核心是四段式角色定义让 Agent 明确自己是资深后端工程师、前端专家还是全栈给它的行为定基调。任务目标用一句话说清楚要交付什么强调可验证的结果。约束条件列出不准做什么、必须遵守什么规范。执行步骤哪怕是粗略的步骤也给 Agent 一个执行路径避免它漫无目的。举个例子我让 Agent 写一个接口的时候不会说帮我写个用户登录接口而是你是一名资深的 Python 后端工程师。请实现用户登录接口要求使用 FastAPI 框架遵循项目现有的目录结构请先阅读项目 README 和 utils/deps.py 了解现状使用 JWT 做身份认证密码用 bcrypt 加密存储。不要修改数据库迁移文件。实现完成后执行项目根目录下的 pytest tests/test_auth.py 验证功能如果测试失败请分析原因并修复后再返回结果。这个 prompt 包含了角色、目标、约束、步骤四个要素。最关键的是我让它先读项目文件再写代码这一步能极大提升生成代码的命中率因为 Agent 不瞎猜你的项目规范了。另外我发现了很多人忽略的一点新版 Claude 和 GPT 对指令和上下文的权重不一样。指令区system prompt里的内容优先级极高而对话历史里的要求可能被遗忘。所以在实操中重要的约束要写进 system prompt而不是聊天中途提一嘴。3.2 记忆管理Agent 的长期记忆和短期记忆Agent 工程化里记忆是最容易被忽视但影响最大的模块。说白了一个 Agent 和另一个 Agent 的区别、一次对话好与坏的区别常常就体现在它记不记得你之前说过什么。记忆分三层短期记忆当前对话窗口里的上下文。这个模型自带但窗口有限超过上下文长度就会遗忘。长期记忆跨会话持久化的信息比如项目的架构说明、编码规范、用户偏好。这个需要外部存储常见方案是向量数据库如 Chroma、Weaviate配合 embedding。工作记忆当前任务执行过程中的中间状态比如已经改了哪些文件测试结果是什么。这个在 LangGraph 里由 State 管理。实战里我强烈建议给每个 Agent 配一个项目知识库文件把项目的技术栈、目录结构、常见注意事项写进去每次任务开始前让 Agent 先读取。这比在对话里反复强调有效得多。原理上这其实是把短期记忆转化为长期记忆减少模型在长对话中的注意力漂移。用一个不太恰当的类比就像你带新同事与其每次任务都重新交代一遍公司规范不如给他一本《新人手册》让他自己翻。Agent 也是一样给它一个好手册效率翻倍。3.3 工具调用与权限边界给 Agent 装手也要装刹车Agent 和聊天机器人的最大区别就是能调用工具。它不只是说还能做——执行 shell 命令、读写文件、调用 API、操作浏览器。这也是为什么 Agent 工程化的落地难度比单纯接一个 API 大得多。工具调用这块要关注三个问题第一工具清单要精简。不要一次性给 Agent 挂 20 个工具它会陷入选择困难而且在关键路径上选错工具的概率会上升。我习惯于把工具按场景分组比如代码编辑三件套read_file、write_file、execute_command再加一个 search_code 就足够覆盖大部分编码任务了。第二权限边界要清楚。Agent 能跑命令很爽但它可能在执行过程中的某个步骤跑了rm -rf或者pip install装了个奇怪的依赖。我的策略是给 Agent 设置一个工作目录白名单只允许它操作当前项目目录下的文件对 shell 命令先做正则过滤禁止高风险操作网络请求走代理层避免它擅自调用外部 API。第三工具调用的结果要反馈到决策中。很多人的 Agent 调用完工具就完事了完全不管输出。这让工具调用变成了单程票Agent 无法根据结果调整下一步动作。正确的做法是工具输出的结果要作为新一轮推理的输入让 Agent 判断这个命令输出是否正常文件写入是否符合预期。4. 多智能体协同的关键机制编排、通信与容错4.1 角色编排从单打独斗到流水线协作多智能体协同最大的价值不是让多个 Agent 一起干活而是让每个 Agent 专注自己擅长的部分通过流水线化的方式提升整体产出质量。我用一个实际的例子说明白。假设你要开发一个用户管理模块单 Agent 模式下它要自己完成需求分析 - 数据库设计 - 后端接口 - 前端页面 - 测试。这条路走下来模型要频繁切换上下文后面会越来越混乱而且你很难在流程中插入人工检查点。在多智能体模式下我把流程拆成了五个角色需求 Agent分析需求文档输出字段定义、接口列表、验收标准。架构 Agent根据需求输出技术选型和数据模型设计。后端 Agent实现接口逻辑操作数据库。前端 Agent实现页面和 API 调用。审查 Agent检查代码规范、潜在 bug、安全漏洞。每个 Agent 的上下文边界清晰不会交叉污染。需求 Agent 只需要关注需求理解和文档输出不用管代码实现细节后端 Agent 拿到的输入是架构 Agent 产出的设计文档它不需要猜测数据结构照着实现就行。这种编排方式用 LangGraph 实现其实不难核心是把数据流定义清楚。4.2 通信机制消息格式比消息内容更重要多智能体协同里Agent 之间传递消息的格式决定了协作的顺畅程度。我见过太多失败的案例问题不在 Agent 能力而是 Agent 之间的接口没有约定好。我的经验是Agent 间的消息必须有发送方、接收方、消息类型、内容主体、时间戳。同时内容主体要有结构化的部分比如交付物文件路径需要确认的问题列表这种字段而不是一堆自然语言文本。举个例子后端 Agent 完成编码后给前端 Agent 发的消息不能是接口写好了你看看而是发送方: backend_agent 接收方: frontend_agent 类型: 接口交付 内容: - 接口地址: /api/users - 方法: GET/POST - 请求参数: {page:int, size:int, name:string} - 响应结构: {data: [...], total: int} - 认证方式: Bearer Token - 示例代码: (附一段 curl 示例)这种结构化消息有几个好处前端 Agent 不需要去翻后端代码就知道怎么对接审查 Agent 可以按字段验证实现是否达标而消息本身也形成了一份可供人工审查的协作留痕。具体落地时我一般用 Pydantic 定义消息 schema在 LangGraph 的状态中直接流转结构化对象而不是传纯字符串。这样每个 Agent 的输入输出都有类型保障排查问题也方便。4.3 容错与重试多 Agent 系统崩溃是常态接受它多智能体系统跟单体程序完全不同它本质上是一个分布式系统失败是常态不是你代码写得差。我在实战营里经常告诉学员你搭建的多 Agent 流程第一次跑通纯属运气跑通之后你要做的是设计容错机制而不是祈祷它每次都能跑通。容错设计我建议从三个层面入手第一是节点级重试。某个 Agent 的某次调用如果返回异常比如模型 API 超时、工具执行出错可以配置重试。重试时要考虑指数退避别在 API 已经限流的时候疯狂重试会雪上加霜。第二是流程级分支。在 LangGraph 里每个节点的输出都可以作为条件分支的依据。比如审查 Agent 如果发现代码存在严重问题流程回到后端 Agent 重写而不是继续往下走如果审查通过才进入测试节点。这种人在环上的设计其实是人不在环上而是规则在环上能防止错误被层层放大。第三是人工兜底。无论系统多完善总有模型搞不定的时候。我在关键节点上比如部署前、合并代码前设置了人工审批Agent 完成任务后不是直接生效而是生成一份交付报告由我确认后才进入下一步。这份报告也是后续排查问题的日志基础。还有一个很多教程不会讲的点多 Agent 系统的状态持久化。你必须在每个节点执行后把状态快照保存下来否则一个节点失败整个流程状态丢失只能从头再来。我用的是 LangGraph 的 State 机制配合 SQLite 或 Redis 做持久化这样即使进程重启也能从最近的快照恢复。5. 实战亲手搭一个多智能体研发流水线5.1 场景设计与技术选型这一节我拿一个完整的实战案例带你跑一遍。目标场景是给一个已有的 FastAPI 项目新增一个文章评论功能包含数据库表、后端接口、前端页面和基础测试。我选用的技术栈是LangGraph 做编排Claude API 作为模型后端你也可以换成其他模型SQLite 做状态存储。这套组合的好处是门槛低、上手快而且生产可扩展。整体流程设计成四个节点analyze_node需求 Agent 读取用户需求和现有项目代码输出功能实现计划。implement_node编码 Agent 按照实现计划写代码。review_node审查 Agent 审查代码质量和潜在 bug。test_node测试 Agent 编写并运行测试用例。流程中若 review 不通过返回第 2 步若 test 失败也返回第 2 步。5.2 LangGraph 核心代码状态定义与节点实现先定义状态。LangGraph 的状态是一种可共享的数据结构每个节点都能读取和修改它。from typing import TypedDict, List, Dict, Any from dataclasses import dataclass class PlanItem(TypedDict): step: str detail: str status: str # pending / done / failed class ReviewResult(TypedDict): passed: bool issues: List[str] suggestions: List[str] class DevState(TypedDict): user_request: str project_path: str plan: List[PlanItem] code_files: List[Dict[str, str]] review: ReviewResult tests_run: bool test_passed: bool error_trace: str状态定义的关键是可序列化因为 Agent 之间传递消息、持久化快照都依赖它。注意不要放不可 JSON 序列化的对象比如模型实例进状态否则会非常痛苦。接着实现节点。我用统一的call_model函数封装对模型的调用传入 system prompt 和 user message返回模型回复文本。这样后续换模型或者加缓存都很方便。from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI import json llm ChatOpenAI(modelgpt-4o-mini, temperature0) def call_model(system: str, user: str) - str: resp llm.invoke([ {role: system, content: system}, {role: user, content: user} ]) return resp.content def analyze_node(state: DevState) - DevState: project_structure read_project_tree(state[project_path]) main_files read_core_files(state[project_path]) prompt f 你是资深软件架构师。用户需求: {state[user_request]} 项目结构: {project_structure} 现有核心文件: {main_files} 请输出一份《功能实现计划》用 JSON 数组格式每个元素包含 step, detail 字段。 计划要具体到改哪些文件、创建哪些文件。 plan_json call_model( 你是严谨的软件架构师只输出 JSON 数组不要多余文字。, prompt ) # 解析 JSON异常时手动修正 try: plan json.loads(plan_json) except json.JSONDecodeError: # 这里做一个简单兜底 plan [{step: fix_plan, detail: 模型输出非合法 JSON已重置计划}] state[plan] plan return state这里需要注意几点模型输出解析必须做容错让 LLM 输出 JSON 时它偶尔会夹带注释、Markdown 代码块标记或者截断。要写一个extract_json函数尽可能宽容地提取 JSON 片段。最笨但最有效的方法是把模型回复用正则取出json ...块再 json.loads。给模型足够上下文read_project_tree和read_core_files这两个函数是我自己写的用于读取项目树结构和核心文件内容。没有这两步Agent 就是在盲人摸象。对于大项目不能全量塞进去要用递进读取策略——先看 README 和配置文件再按需读取核心模块。接下来是 implement_node它读取分析节点生成的计划逐条实现。def implement_node(state: DevState) - DevState: plan state[plan] project state[project_path] completed_files [] for item in plan: step item[step] detail item[detail] system_prompt f 你是资深全栈工程师。项目目录: {project} 遵循项目现有代码风格只允许在项目目录内创建或修改文件。 不要安装额外依赖除非用户明确要求。 每完成一个文件用一句话描述实现内容。 result call_model(system_prompt, f请实现{step}\n{detail}) # 这里关键让 Agent 自己调用工具写文件 # 实际项目中你会让 Agent 返回 JSON包含 file_path 和 file_content # 再在你的 Python 代码里写入磁盘而不是让模型直接操作系统 written write_files_from_agent_result(project, result) completed_files.extend(written) # 中间状态更新如果某一步失败填入 error_trace 并中断 state[code_files] completed_files return state关于Agent 如何操作文件这里有个设计哲学层面的选择是用execute_command让 Agent 自己用 shell 写文件还是让 Agent 输出文件内容、由你控制写入我强烈推荐后者——Agent 只负责生成内容你负责执行。这样可控性最好能防止 Agent 乱建目录、乱改权限。换句话说你的框架代码是 Agent 的手只不过这只手长了你的眼睛。5.3 流程编排图的定义与执行入口在 LangGraph 中定义流程图很简单关键是条件边的写法。from langgraph.graph import StateGraph, END g StateGraph(DevState) g.add_node(analyze, analyze_node) g.add_node(implement, implement_node) g.add_node(review, review_node) g.add_node(test, test_node) g.set_entry_point(analyze) g.add_edge(analyze, implement) # review 通过进入 test不通过回到 implement g.add_conditional_edges( review, lambda state: pass if state[review][passed] else fail, {pass: test, fail: implement} ) # test 通过结束不通过回到 implement带错误信息 g.add_conditional_edges( test, lambda state: pass if state[test_passed] else fail, {pass: END, fail: implement} ) app g.compile()这段代码的核心逻辑是流程沿着分析 - 实现 - 审查 - 测试的路径走审查不通过就回到实现节点改测试不通过也回到实现节点改。这种带反馈环的图结构真实软件开发里每天都在发生只是以前是人肉反馈现在交给你定义的规则。执行入口就很简单了initial_state { user_request: 给现有 FastAPI 项目新增文章评论功能, project_path: ./my_fastapi_project, plan: [], code_files: [], review: {passed: False, issues: [], suggestions: []}, tests_run: False, test_passed: False, error_trace: } final_state app.invoke(initial_state) print(审查结果:, final_state[review]) print(测试通过:, final_state[test_passed]) print(修改文件:, final_state[code_files])跑完之后你可以把整个状态打印出来看每个节点的产出。这就是调试多 Agent 系统最直接的方式——看状态流转哪里出问题一目了然。5.4 实战效果单 Agent 和多 Agent 的对比我用这个多 Agent 流水线跑过同一个需求对比单 Agent 直接写的效果维度单 Agent 直接写多 Agent 流水线代码质量能用但风格不一致模块边界模糊模块边界清晰风格接近项目现有代码缺陷数首次提交平均 4-5 个问题首次提交平均 1-2 个问题可维护性注释稀缺命名不规范审查 Agent 会强制补充注释和规范命名耗时8 分钟15 分钟含审查、测试环节多 Agent 慢一倍但产出质量明显高一个档次。关键差异在 review 节点——审查 Agent 用一套独立的视角检查编码 Agent 的输出相当于写代码的人和审代码的人分离了这在人类团队里是基本常识在多智能体系统里同样成立。成本方面也要说实话多 Agent 模式下 token 消耗大概是单 Agent 的 2.5 倍因为审查、测试每个环节都需要额外的模型调用。但考虑到返工成本的下降总体性价比其实更高。我的建议是小需求、一次性脚本用单 Agent 就够核心业务模块、需要长期维护的功能上多 Agent 流水线。6. 常见问题与排查技巧实录6.1 多 Agent 系统典型问题速查表在实战营带学员的过程中我总结了一份出现频率超高的问题和排查思路直接给你做成了速查表问题现象可能原因排查步骤解决办法Agent 不按指示执行Prompt 里约束项太多模型忽略了靠后的指令检查 system prompt 的长度和顺序把最重要的约束放最前面拆分成多条短指令生成的代码风格与项目不符未向 Agent 提供项目现有代码样本检查喂给 Agent 的上下文是否包含核心代码增加read_core_files步骤并附上 2-3 个现有函数作为风格参考Agent 频繁调用错误工具工具列表过长选择困难查看调用日志中的工具名和参数精简工具数量放大工具描述中的适用场景多 Agent 之间消息格式解析失败消息文本夹带 Markdown 标记检查模型输出解析逻辑在 prompt 中强制只输出 JSON用正则提取代码块后再解析流程卡死或无限循环条件边判断逻辑有误检查条件函数是否覆盖所有分支打印状态中的条件字段增加最大循环次数限制测试节点报错但编码节点无法修复Agent 拿不到测试输出的完整信息检查状态里是否传递了测试日志把 pytest 输出写入状态error_trace编码节点读取后修复这个表就是我的排查手册每次遇到类似问题直接对照省很多时间。6.2 避坑技巧三个让我少走一年弯路的心得第一个心得Agent 的上下文工程比 Prompt 工程重要十倍。很多人花很多精力调 System Prompt把每个词都打磨得很精致但完全忘了喂给 Agent 的文件内容。对模型来说上下文里的代码示例、项目结构、测试用例才是它做判断的核心依据。我的习惯是在任何 Prompt 优化之前先问自己Agent 能看到它需要的全部信息吗——看不到的话Prompt 写得再花哨也是白搭。第二个心得结构化输出是 Agent 工程化的生命线。如果你让 Agent 输出自然语言你会得到一段漂亮但难以编程处理的话。正确做法是让 Agent 输出结构化数据——JSON 或 YAML然后在你的代码里解析校验。解析失败就重试重试还失败就降级处理。有了结构化输出你才能把 Agent 接到自动化流程里否则只能在交互式界面里人肉复制粘贴那离工程化太远了。第三个心得人机协作界面HITL不是可选项是生产系统的必需品。多智能体系统能力越强出问题时的破坏力也越大。一个 Agent 可能因为一条错误指令删掉整个目录或者给代码注入恶意依赖。所以我的生产系统里任何涉及删除部署安装依赖的操作都必须经过人工确认。哪怕牺牲一点自动化率也要保证系统的可控性。这个原则帮我避免了好几次可能的事故。6.3 效率优化缓存、并行与模型分级最后分享一个又能提效又能省钱的策略任务分级 缓存复用。模型分级的意思是不要把高成本的大模型用在所有任务上。需求分析、代码审查这类理解型任务用能力强的模型而代码生成、内容总结这类生成型任务如果上下文不大用速度更快的轻量模型也行。我在 LangGraph 里给每个节点指定不同的模型整体成本大概降了 40%。缓存复用则是利用 LangChain 的缓存机制对完全相同的模型调用直接返回缓存结果。多 Agent 协同中审查节点和测试节点经常要用到同样的文件内容、同样的上下文缓存能显著减少重复计费。并行方面LangGraph 的 fan-out 机制可以让多个独立任务同时跑。比如测试节点要跑三个测试文件三个测试 Agent 可以并行执行而不用串行排队。但要注意并行会带来状态合并的问题需要确保各分支写入的状态字段没有冲突。我的经验是并行节点尽量写入不同的状态 key不要都往同一个字段里塞数据。这些优化加在一起让我的多 Agent 流水线从能跑变成了又快又稳又能接受。最后再分享一个我自己的体会Agent 工程化最迷人的地方是它逼着你用管理学的思维去做软件工程。你不再只是写代码而是要定义角色、设计协作流程、建立质量标准、规划容错机制——就像在管理一个由 AI 组成的小团队。这套方法论学会之后受益的绝对不只是 AI 编程这一个场景。你看问题的视角会从我怎么把代码写出来变成我怎么能让别人哪怕是 AI稳定地、高质量地、可复现地把代码写出来。这个转变我觉得才是 Agent 工程化真正的价值所在。
