1. 为什么设计稿与代码之间总有一道人工翻译的墙做前端或者全栈的朋友大概都有过这种体验产品经理甩过来一个设计稿链接说“就按这个做”然后你打开一看图层命名全是 Frame 427、Rectangle 18、Group 233光是理清哪个图层对应哪个组件就要花掉小半天。更别提改稿阶段设计侧微调了一个间距、换了一个圆角你这边得手动去代码里翻对应的样式改完还要截图比对来回确认。这个过程中最耗时的不是写代码本身而是“人肉解析设计稿”这个环节。Figma 作为目前主流的界面设计工具本身提供了插件体系和 REST API理论上可以让机器直接读取设计稿的结构化数据。但现实情况是很多团队用的免费版账号在 API 调用上有额度限制或者干脆没有开放某些接口权限。于是就有了一个很实际的需求能不能在不购买付费套餐的前提下让本地的 AI Agent 直接读懂 Figma 设计稿甚至反过来修改它Local Figma Agent MCP 就是冲着这个场景来的。它本质上是一个运行在本地的 MCP 服务通过 Figma 桌面端提供的插件运行环境把设计稿的节点树、样式属性、组件信息暴露给本地的 Agent 进程。Agent 拿到这些结构化数据之后就可以做代码生成、样式比对、批量重命名、甚至反向修改设计稿的操作。整个过程不依赖 Figma 的云端付费 API走的是本地插件通道所以免费账号也能跑通。这篇文章适合三类人看一是前端开发者想减少设计稿到代码的手动翻译成本二是设计系统维护者需要批量处理图层命名和组件规范三是对 MCP 协议和 Agent 工具链感兴趣的工程师想了解本地 Agent 如何与设计工具打通。我会从原理、环境搭建、核心操作、踩坑经验几个维度展开尽量把每个环节的“为什么”讲清楚让你看完能直接上手复现。2. Local Figma Agent MCP 到底在做什么拆解本地插件通道的工作机制2.1 MCP 协议在这里扮演什么角色MCP 全称 Model Context Protocol你可以把它理解成一套“Agent 和外部工具之间的通用插头标准”。在没有这套标准之前Agent 想调用一个外部能力得针对每个工具单独写适配代码今天接 Figma 写一套明天接数据库又写一套维护成本很高。MCP 的思路是定义统一的通信格式Agent 侧作为客户端工具侧作为服务端双方通过标准化的请求和响应来交互。Local Figma Agent MCP 就是把这个服务端跑在本地。它启动之后会监听一个本地端口Agent 通过这个端口发送指令比如“获取当前选中节点的属性”“列出所有文本图层的字体信息”“把某个节点的填充色改成指定值”。服务端收到指令后转译成 Figma 插件 API 能理解的调用执行完再把结果回传给 Agent。整个链路都在本机完成不经过外部服务器所以响应速度快也不受账号套餐的 API 额度限制。这里有个关键点需要理解Figma 插件 API 和 Figma REST API 是两套不同的东西。REST API 是走网络的受套餐和权限约束插件 API 是运行在 Figma 桌面端或浏览器端插件沙箱里的只要插件被加载就能访问当前文档的节点树。Local Figma Agent MCP 走的是后者所以才能绕开付费限制。当然这也意味着它只能操作“当前打开的那个文档”没法在后台批量处理一堆文件这是它的能力边界。2.2 本地插件通道的数据流转过程把整个数据流转拆开看大概是这么几步。第一步你在 Figma 桌面端加载 Local Figma Agent MCP 对应的插件插件启动后会建立一个本地通信通道通常是一个 WebSocket 或者本地 HTTP 服务。第二步你在本地启动 Agent 进程它作为 MCP 客户端去连接这个通道。第三步Agent 发送指令插件在 Figma 沙箱内执行对应的 API 调用拿到节点数据。第四步数据经过序列化后回传给 AgentAgent 再决定下一步做什么。这个过程中最容易被忽略的是“节点树的序列化”。Figma 的节点树可能非常深一个页面里嵌套几十层 Group 是常事。如果一次性把整棵树拉过来数据量会很大Agent 处理起来也慢。所以实际使用中通常的做法是先拉顶层节点按需展开。比如先获取当前选中的节点或者按名称过滤出特定类型的节点再逐层深入。这个策略和爬虫的“按需抓取”是一个道理避免一次性加载过多无用数据。另一个细节是样式属性的读取。Figma 里一个矩形的填充可能来自样式库、可能来自本地样式、也可能是直接设置的色值。插件 API 能区分这些来源但 Agent 拿到数据后需要自己判断优先级。比如做代码生成时如果填充来自共享样式那生成的代码应该引用对应的设计令牌而不是硬编码色值。这个判断逻辑需要在 Agent 侧实现MCP 服务本身只负责把原始数据吐出来。2.3 不买付费套餐能用到什么程度免费账号在 Figma 里的限制主要是协作人数、版本历史和部分云端 API 额度。Local Figma Agent MCP 走本地插件通道所以协作和版本历史这些限制不影响它。它能做的事情包括读取当前文档的完整节点树、读取和修改节点属性、创建和删除节点、批量重命名、导出节点为图片或 SVG。基本上插件 API 能做的它都能通过 Agent 来触发。做不到的事情也要说清楚它没法访问你没有打开的文件没法跨文件批量操作没法读取团队库的完整元数据部分库信息在插件 API 里是受限的。所以如果你的需求是“每天晚上自动扫描团队所有设计稿并生成报告”那这个方案不合适还是得走云端 API。但如果你的需求是“在当前打开的设计稿里让 Agent 帮我批量改图层名、提取样式、生成组件代码”那它完全够用。3. 从零搭起本地 Agent 与 Figma 的通信链路3.1 环境准备别急着装插件先把这几样确认好动手之前先把基础环境理清楚。你需要的东西不多但每一样都有坑。首先是 Figma 桌面端注意是桌面端不是浏览器端。虽然浏览器端也能跑插件但本地通信通道在桌面端更稳定而且桌面端对本地文件系统的访问权限更宽松后续如果要导出文件会方便很多。版本方面建议保持最新老版本插件 API 可能有差异。然后是 Node.js 环境。Local Figma Agent MCP 的服务端和插件构建脚本通常依赖 Node 工具链建议用 LTS 版本别用太新的实验版避免依赖包兼容问题。装完之后确认 npm 或 pnpm 能正常工作。如果你习惯用 yarn 也行但要注意锁文件的一致性别混用。第三样是 Agent 运行环境。这个取决于你用哪个 Agent 框架有的用 Python有的用 Node。关键是确认你的 Agent 支持 MCP 客户端功能。如果不支持就得自己写一层适配把 MCP 的请求格式转成 Agent 能理解的工具调用格式。这一步是很多人在搭建时卡住的地方因为文档里往往默认你已经有一个支持 MCP 的 Agent 了。最后确认一下端口占用情况。本地 MCP 服务通常会监听一个固定端口比如 3000 或者 8080 附近的某个值。如果这个端口被其他服务占了启动时会报错。建议提前用命令行查一下端口占用或者直接在配置里改成一个不常用的端口省得后面排查。3.2 插件侧的加载与调试为什么你的插件面板是空的插件加载这一步最常见的现象是“面板打开了但一片空白”或者“提示连接失败”。先说空白的情况。这通常是因为插件的 UI 线程和主线程通信出了问题。Figma 插件分两部分一部分是运行在沙箱里的主逻辑能访问 Figma API另一部分是 UI 面板运行在 iframe 里负责展示界面。两者通过 postMessage 通信。如果 UI 面板加载了但没收到主逻辑的数据就会空白。排查方法是打开 Figma 的插件开发控制台看有没有报错。常见错误包括UI 的 HTML 文件路径写错了、构建产物没有正确输出、或者跨域限制导致 iframe 里的脚本加载失败。如果是用构建工具打包的确认一下输出目录和插件 manifest 里配置的路径是否一致。这个坑我踩过好几次每次都是路径问题。连接失败的情况多半是本地 MCP 服务没启动或者端口对不上。插件侧一般会有一个配置项让你填本地服务的地址和端口确认这个配置和服务端实际监听的一致。另外注意有些系统对本地回环地址的访问有额外限制如果填的是 localhost 不通可以试试换成 127.0.0.1反过来也一样。这个细节很小但确实会卡住人。3.3 Agent 侧的配置把 MCP 服务注册成可用工具Agent 侧要做的核心事情是把 Local Figma Agent MCP 注册成一个可调用的工具。不同 Agent 框架的注册方式不一样但思路是相通的你需要告诉 Agent“有一个叫 figma-local 的工具它的能力描述是什么怎么连接它”。能力描述很重要它决定了 Agent 在什么情况下会主动调用这个工具。描述写得太模糊Agent 可能该调用的时候不调用写得太宽泛又可能在不相关的场景下乱调用。一个实用的做法是在工具描述里明确列出几个典型操作比如“读取当前选中节点的属性”“按名称查找节点”“修改节点填充色”“批量重命名图层”。这样 Agent 在遇到类似需求时更容易匹配到这个工具。同时在 Agent 的系统提示里也可以加一句引导比如“当用户提到设计稿、Figma、图层、组件时优先考虑使用 figma-local 工具”。这种引导不是必须的但实测能明显提升调用准确率。配置完成后先做一个最简单的连通性测试让 Agent 调用工具获取当前选中节点的名称。如果返回了正确的名称说明链路通了。如果报错根据错误信息逐段排查是 Agent 没找到工具还是工具连不上服务还是服务连不上插件。分段定位比整体调试效率高得多。4. 让 Agent 真正读懂设计稿节点解析与语义提取的实操细节4.1 节点树的读取策略一次性拉取还是按需展开前面提到过节点树可能很深一次性拉取不现实。实际操作用的是“分层读取”策略。第一步获取当前页面的顶层节点列表通常数量不多几十个以内。第二步根据 Agent 的任务目标决定展开哪些子树。比如任务是“找出所有按钮组件”那就按名称或类型过滤只展开可能是按钮的节点。第三步对目标节点读取详细属性包括尺寸、位置、填充、描边、圆角、字体等。这个策略的好处是数据量可控Agent 的处理速度快。坏处是需要多轮交互如果 Agent 的规划能力不强可能会漏掉一些节点。为了减少遗漏可以在工具侧提供一个“递归查找”的接口让 Agent 指定一个过滤条件服务端在 Figma 沙箱内递归遍历只返回匹配的节点。这样把遍历逻辑放在服务端Agent 只需要发一次请求效率更高。过滤条件的写法很关键。Figma 节点有 type 属性比如 FRAME、TEXT、RECTANGLE、COMPONENT、INSTANCE 等。按 type 过滤是最常用的。另外还可以按 name 做模糊匹配按是否可见过滤按是否有特定插件数据过滤。组合使用这些条件能比较精准地定位到目标节点。我一般会建议在工具描述里把这些过滤能力写清楚方便 Agent 自己组合。4.2 样式信息的语义化从原始属性到设计令牌拿到节点的原始属性只是第一步真正有价值的是把这些属性语义化。举个例子一个矩形的填充色是 #1A73E8这是原始数据。但如果这个色值来自一个叫“Primary/Blue/500”的共享样式那语义就是“主色蓝 500”。Agent 在做代码生成时应该优先使用语义化的设计令牌而不是硬编码色值。这样后续设计令牌变更时代码只需要改一处。实现这个语义化需要在读取节点属性时同时读取它引用的样式 ID然后再去样式表里查这个 ID 对应的名称。Figma 插件 API 提供了获取本地样式和共享样式的方法。需要注意的是共享样式的读取在某些权限下可能受限如果读不到就退而求其次用本地样式或者直接用原始值加一个标记提示 Agent 这里可能需要人工确认。字体信息也是类似的处理。一个文本节点的字体可能是“Inter Regular 14px”但设计系统里可能定义的是“Body/Regular”这样的令牌。Agent 需要根据字体名称、字重、字号去匹配设计令牌表。这个匹配逻辑可以放在 Agent 侧也可以放在 MCP 服务侧提供一个“解析样式令牌”的工具。放在服务侧的好处是复用性强多个 Agent 都能用放在 Agent 侧的好处是灵活可以根据不同项目的令牌规范调整。4.3 组件与实例的识别区分主组件和派生实例Figma 里组件和实例的关系类似于面向对象里的类和对象。主组件定义结构和默认样式实例继承主组件但可以覆盖部分属性。Agent 在处理设计稿时必须能区分这两者否则生成的代码会出问题。比如一个按钮的主组件改了圆角所有实例都会跟着变但如果某个实例单独覆盖了圆角那它就不受主组件影响。读取节点时INSTANCE 类型的节点会有一个 componentId 指向主组件。Agent 可以通过这个 ID 去获取主组件的属性然后对比实例的覆盖属性判断哪些是继承的、哪些是覆盖的。这个信息对代码生成很重要继承的属性可以抽成公共样式覆盖的属性需要单独处理。如果 Agent 不区分这些生成的代码就会把所有属性都写死失去组件化的意义。另外组件的命名规范也影响 Agent 的理解。如果主组件叫“Button/Primary/Large”Agent 很容易推断出这是一个大号主按钮。如果叫“Frame 427”那就只能靠属性推断准确率会下降。所以我在实际项目中会建议设计侧尽量规范命名这不仅对人友好对 Agent 也友好。如果命名已经乱了可以先让 Agent 做一轮批量重命名把命名规范起来再去做后续的代码生成。5. 反向操作让 Agent 修改设计稿的边界与注意事项5.1 哪些修改是安全的哪些容易出问题让 Agent 修改设计稿听起来很美好但实际操作中要区分场景。安全的修改包括批量重命名图层、统一修改填充色或描边色、调整间距和圆角、替换文本内容、显示或隐藏特定图层。这些操作的影响范围明确出错了也容易回滚。不安全的修改包括删除节点、改变节点层级结构、替换主组件、修改自动布局的关键参数。这些操作一旦出错可能破坏整个设计稿的结构恢复起来很麻烦。我的建议是在让 Agent 做任何修改之前先手动保存一个版本或者复制一份文档出来操作。Figma 的版本历史在免费版里有限制别指望靠它回滚。复制文档是最稳妥的改坏了直接删掉副本就行。另外修改操作最好分批进行改完一批检查一批别一次性让 Agent 跑完所有修改出了问题都不知道是哪一步导致的。还有一个细节是自动布局。Figma 的自动布局Auto Layout有一套自己的约束逻辑Agent 修改子节点尺寸或间距时可能会触发自动布局的重新计算导致意料之外的位移。如果设计稿大量使用自动布局建议 Agent 在修改前先读取布局配置修改后验证布局是否还符合预期。这个验证步骤不能省否则改完一看全乱了。5.2 批量重命名的实战策略批量重命名是 Agent 修改设计稿里最高频、也最实用的操作。一个典型场景是设计稿从其他工具导入图层名全是默认的“Rectangle 1”“Group 2”需要按规范重命名。Agent 可以根据节点的类型、尺寸、位置、内容来推断合理的名称。比如一个 375x812 的 Frame 可能是手机屏幕一个包含文本且宽度较小的节点可能是按钮。具体策略可以分几步。第一步按类型分组FRAME 归 FRAMETEXT 归 TEXTCOMPONENT 归 COMPONENT。第二步对每组内的节点根据尺寸和位置排序推断层级关系。第三步结合文本内容或已有命名生成候选名称。第四步批量应用重命名并输出一份变更日志方便人工复核。这个流程里变更日志很重要因为 Agent 的推断不可能百分之百准确人工复核是必要的兜底。重命名时还要注意命名冲突。如果两个节点被推断成同一个名称后续引用会出问题。解决办法是在名称后加序号或者用更细粒度的特征来区分。比如两个都是按钮一个宽度 120一个宽度 200可以命名为“Button/Small”和“Button/Large”。这个逻辑可以在 Agent 侧实现也可以做成 MCP 服务的一个工具让 Agent 调用。5.3 修改后的验证怎么确认 Agent 没把设计稿改坏修改完成后的验证环节很多人会忽略但它恰恰是最重要的。验证分两个层面结构验证和视觉验证。结构验证是检查节点树是否完整有没有节点丢失层级关系是否还正确。这个可以通过对比修改前后的节点数量和层级深度来快速判断。如果修改前有 500 个节点修改后只剩 480 个那肯定有问题得排查哪里丢了。视觉验证是导出修改后的关键页面截图和修改前的截图做比对。如果只是重命名视觉上应该完全一致如果有样式修改视觉差异应该符合预期。这个比对可以人工做也可以让 Agent 做。Agent 做的话需要能读取图片并做像素级或结构级比对。像素级比对对渲染差异很敏感结构级比对更实用比如比对两个截图的布局网格是否一致。我自己的习惯是每次让 Agent 做批量修改后都会让它输出一份“修改摘要”包括修改了哪些节点、改了什么、预期效果是什么。然后我拿着这份摘要去抽查几个关键节点确认无误后再继续下一步。这个习惯帮我避免了好几次潜在的事故尤其是涉及组件和自动布局的修改。6. 踩坑记录那些文档里不会写的实际问题6.1 插件沙箱的权限限制与绕行思路Figma 插件沙箱对某些 API 的调用是有限制的比如网络请求、本地文件系统访问、部分跨文档操作。Local Figma Agent MCP 走本地通信通道本身不涉及网络请求所以网络限制不影响它。但文件系统访问受限会影响导出功能。如果你想让 Agent 把设计稿导出成图片或 SVG 并保存到本地插件沙箱可能不允许直接写文件。绕行思路是插件侧把导出的数据通过本地通道传给 MCP 服务由服务侧负责写文件。服务侧运行在 Node 环境里没有沙箱限制可以自由读写本地文件。这个分工很关键插件负责和 Figma 交互服务负责和本地系统交互Agent 负责决策和调度。三层各司其职边界清晰出问题也容易定位是哪一层的毛病。另一个权限限制是跨文档操作。插件只能访问当前打开的文档没法在后台打开另一个文档并操作它。如果你的需求涉及多个文档只能手动切换或者用 Figma 的 REST API但那就回到付费额度的问题了。这个限制目前没有太好的绕行方案只能接受。所以在规划任务时尽量把同一文档的操作集中在一起减少切换成本。6.2 大文档下的性能瓶颈与优化设计稿节点数量超过几千个时性能问题会很明显。插件 API 的调用本身有开销每次读取节点属性都要跨沙箱边界累积起来很慢。如果 Agent 还在一轮轮地发请求整体耗时可能从几秒变成几分钟。优化思路有几个一是减少请求次数把多个读取操作合并成一个批量请求二是缓存已读取的节点数据避免重复读取三是限制遍历深度非必要不展开深层子树。批量请求的实现方式是在 MCP 服务侧提供一个“批量读取”接口接受一个节点 ID 列表一次性返回所有节点的属性。这样 Agent 只需要发一次请求服务侧在 Figma 沙箱内循环读取虽然总开销差不多但省去了多次通信的往返时间。实测下来批量读取比逐个读取能快三到五倍节点越多差距越明显。缓存策略也要注意失效问题。如果 Agent 读取了节点数据然后修改了某个节点缓存里的数据就过期了。简单的做法是修改后清空相关节点的缓存或者干脆每次修改后重新读取。复杂一点的做法是维护一个版本号每次修改递增读取时检查版本号决定是否用缓存。这个看具体场景如果修改不频繁简单清空就够了。6.3 Agent 误操作后的回滚方案Agent 误操作是难免的关键是怎么快速回滚。前面说过最稳妥的方式是操作前复制文档。但复制文档有个问题复制出来的文档和原文档是独立的Agent 操作的是副本你确认无误后还得把改动同步回原文档。如果改动很多同步本身也是工作量。所以这个方案适合改动量大、风险高的场景日常小改动没必要这么重。轻量级的回滚方案是利用 Figma 的撤销功能。插件 API 触发的修改在 Figma 里是可以撤销的只要在同一个会话里。所以如果 Agent 改错了立刻在 Figma 里按撤销快捷键通常能恢复。但要注意撤销栈有深度限制如果 Agent 连续做了很多步修改可能撤不回去。所以还是建议分批操作每批做完确认一下确认无误再继续。还有一个兜底方案是让 Agent 在修改前先记录原始值。比如要改一个节点的填充色先读取当前色值存下来修改后如果发现问题可以用存下来的原始值改回去。这个方案需要 Agent 有“记录-修改-回滚”的完整逻辑实现起来稍微复杂但对关键操作很值得。我一般会在涉及组件和布局的修改上用这个方案普通的重命名和样式微调就不必了。7. 把 Agent 接入日常设计开发流程的几种玩法7.1 设计稿转代码从节点树到组件代码的映射这是最直接的玩法。Agent 读取设计稿的节点树识别出组件和布局生成对应的前端代码。映射规则可以自定义比如 FRAME 映射成 divTEXT 映射成 span 或 pINSTANCE 映射成组件引用。样式方面填充色映射成 background-color描边映射成 border圆角映射成 border-radius自动布局映射成 flex 或 grid。这个过程中最麻烦的是布局推断。Figma 的自动布局和 CSS 的 flex 不是一一对应的有些自动布局的配置在 CSS 里需要额外的处理。比如 Figma 里的“间距自动”在 CSS 里可能是 gap也可能是 margin取决于具体场景。Agent 需要根据节点的实际布局结果来反推最合适的 CSS 写法而不是机械地翻译属性。这个推断逻辑需要一些启发式规则准确率不可能百分之百但能省掉大部分手动工作。生成的代码质量还取决于设计稿的规范程度。如果设计稿用了规范的组件和命名生成的代码结构会很清晰如果全是散乱的 Frame 和 Rectangle生成的代码就是一堆嵌套 div可读性很差。所以这个玩法的前提是设计稿本身有一定的规范性。如果设计稿不规范可以先做一轮规范化处理再生成代码。7.2 设计规范检查让 Agent 当你的设计 lint 工具设计稿里经常会出现不规范的地方用了不在设计系统里的色值、字体大小不在预设范围内、间距不是 4 的倍数、组件实例被解绑了等等。这些检查人工做很费时让 Agent 做就很合适。Agent 遍历节点树对每个节点检查预设的规则输出违规列表。规则可以配置比如“所有填充色必须来自共享样式”“所有字号必须是 12/14/16/20/24 之一”“所有间距必须是 4 的倍数”。这个玩法的价值在于它把设计规范的执行从“事后人工检查”变成了“随时自动检查”。设计侧改完稿跑一下 Agent立刻知道哪里不合规改完再跑直到通过。这比等到开发阶段才发现问题要高效得多。而且规则可以随设计系统演进不断更新Agent 的检查逻辑也跟着更新保持一致性。实现上检查规则可以写成配置文件Agent 读取配置后逐条执行。每条规则对应一个检查函数输入是节点属性输出是是否通过和违规详情。这个架构很灵活新增规则只需要加一个函数和一条配置。我见过一些团队把这种检查集成到 CI 里设计稿更新后自动跑结果发到群里效果不错。7.3 设计稿差异比对改版前后的自动化 diff产品迭代时设计稿经常改版。改版前后有哪些差异人工比对很费眼。Agent 可以做自动化 diff读取两个版本的节点树按节点 ID 或名称匹配找出新增、删除、修改的节点输出差异报告。这个报告可以细化到属性级别比如“按钮的主色从 #1A73E8 改成了 #1B74E9”“卡片圆角从 8px 改成了 12px”。这个玩法的难点在于节点匹配。如果改版时节点 ID 变了就得靠名称和位置来匹配准确率会下降。所以最好在设计侧约定改版时尽量保留节点 ID或者至少保留名称。如果做不到Agent 的 diff 结果就需要人工复核但即便如此也比纯人工比对快很多。差异报告的输出格式可以很灵活简单的就是文本列表复杂点的可以生成 HTML 报告带截图对比。截图对比需要导出节点图片然后并排展示。这个在 MCP 服务侧实现比较方便因为服务侧可以写文件生成 HTML 报告后直接在浏览器打开看。我一般会生成一个简单的 HTML左边是改前截图右边是改后截图下面列出属性差异一目了然。8. 关于这套方案的能力边界与后续扩展方向用了一段时间下来我的整体感受是Local Figma Agent MCP 这套方案在“单文档、中等规模、规范化设计稿”的场景下表现很好能实实在在省掉大量重复劳动。但它不是万能的跨文档批量处理、超大文档的性能、非规范设计稿的理解准确率这些方面还有明显的天花板。所以我的建议是先在小范围试点跑通一个具体场景比如“批量重命名”或“设计规范检查”确认效果后再逐步扩大使用范围。扩展方向上我觉得有几个值得探索的点。一是把 MCP 服务和 CI 流程结合设计稿更新后自动跑检查和 diff结果推送到协作工具。二是把 Agent 的修改能力做成“建议模式”Agent 只输出修改建议人工确认后再执行降低误操作风险。三是积累一套针对自己团队设计系统的规则库和提示词模板让 Agent 的理解准确率随着使用不断优化。这些方向都不需要额外的付费成本靠本地工具链就能实现。最后说一个实际体会这套方案的价值不在于“完全替代人工”而在于“把人工从重复劳动里解放出来”。Agent 做批量处理人做关键决策和复核这个分工目前是最务实的。指望 Agent 全自动搞定一切现阶段还不现实但让它承担百分之七八十的机械工作完全可行。我在实际项目里就是这么用的效率提升很明显而且随着规则和提示词的积累Agent 的表现会越来越好。
