如果你跟我一样是从第一篇一路刷到第七篇的大概率已经对 Google Antigravity 能做什么有了轮廓它把大模型、工具调用、业务流程串成一个能自主干活的 Agent而且尽量不让代码成为门槛。前面几篇讲概念、架构、外部服务接入看着都清楚可真到自己打开工作台的那一刻很多人会愣在原地——界面上的东西比想象中多左一个面板右一个按钮不知道先点哪里。第 7 篇不绕弯子专门把编辑器这一关讲透。这篇文章适合两类人一是刚把 Antigravity 项目建起来、还没理清编辑器布局的新手二是已经能跑通简单对话但想搞明白工作流画布、调试面板和发布流程之间是怎么衔接的人。1. 为什么讲完前面六篇才轮到编辑器这关1.1 编辑器的定位不是代码 IDE而是 Agent 装配台很多人第一次打开 Antigravity会下意识把它类比成写代码用的编辑器然后开始找代码文件、找命令行。这个类比从一开始就错了。Antigravity 的编辑器更像是一条装配流水线你不需要面向源码编程而是面向这个 Agent 应该怎么干活来组织一切。你要做的是选模型、写指令、挂工具、连流程用可视化的方式把这些零件拼起来。这样设计的好处很明显产品的核心产物是 Agent 本身而不是一段程序。你在编辑器里看到的所有节点、连线、配置项本质上都在描述这个 Agent 的行为逻辑。编辑器承担了三件事定义 Agent 的行为边界、设计 Agent 执行任务的流程、验证 Agent 是否真的按预期工作。理解了这一点你就知道为什么教程把编辑器排在比较靠后的位置——前面的概念没建立起来直接打开编辑器只会看到一堆不知所云的按钮。1.2 打开编辑器前的环境准备第一次进入编辑器建议不要急着拖节点。先花五分钟做两件小事。第一确认你打开的是项目级工作区而不是某个独立会话。Antigravity 里一个项目可能包含多个 Agent编辑器打开后你要能分清当前处于哪个 Agent 的编辑界面不然很容易把配置写错地方。第二想清楚是从空白项目开始还是从模板开始。模板的好处是能快速看到完整流程长什么样坏处是你不知道预设逻辑里藏了什么。我见过有人用模板改了一个下午最后发现 Agent 莫名其妙地多调了一个翻译工具就是模板自带的。纯新手我更推荐从空白项目开始先把面板认一遍再决定要不要往里面加东西。1.3 这一篇你会走完的路径我习惯把编辑器相关的操作分成五个阶段认识工作区、配置 Agent 行为、搭可视化流程、调试验证、发布上线。这篇就按这个顺序展开每一步都会给出具体操作和判断依据。读完以后你应该能独立完成一个带工具调用、有明确流程分支、经得起测试的 Agent而不是只会玩对话玩具。2. 工作区界面拆解四个区域各管什么事2.1 左侧组件库LLM 节点、工具节点、控制节点Antigravity 编辑器最左侧是组件库看起来像一堆可拖拽的卡片。这些组件大致分三类。第一类是 LLM 相关节点比如文本生成、摘要、改写、分类判断。它们负责动脑是 Agent 的认知核心。第二类是工具节点比如内置搜索、代码执行器、HTTP 请求、文档解析。它们负责动手是 Agent 与外部世界交互的通道。第三类是控制节点比如条件判断、循环、延迟、失败分支。它们负责走流程决定任务按什么路径执行下去。选择组件时不要按名字一个个试而是先想清楚Agent 干活的这个步骤属于思考、调用、还是分流。想清楚动作类型再去组件库找对应的卡片就很快。这种分类思维比死记硬背组件名字有用得多。2.2 中央画布从空白的第一个节点开始中间的大片区域是画布所有流程都在这里搭建。第一次打开画布是空的别慌。我建议的第一个操作是从组件库里拖一个LLM 生成节点到画布中间。拖进来之后你会看到节点四周有接口右边是输出左边是输入。把鼠标放到右侧接口上拖出去会出现一条虚线拉到下一个节点的左侧接口上就完成了一次连接。一个最简三节点流程大概长这样接收用户问题 → 调用搜索工具 → 生成回答。先拖一个用户输入节点把它连接到搜索工具节点再把搜索工具连接到LLM 生成节点。这样就完成了 Agent 最基本的一条执行链。画布操作有几个小地方值得记一下空白处拖拽可以平移画布滚轮缩放这跟地图操作差不多。双击节点能直接打开配置面板比每次去右侧面板点更快。画布右上角的自动整理按钮能让连线杂乱无章的节点重新排列整齐流程一长这个功能很救命。2.3 右侧配置面板选中什么就配置什么画布右侧是配置面板特点是随选随变你在画布上选中哪个节点面板里就显示哪个节点的配置项。这种交互模式对新手特别友好不用记一堆菜单层级只需要记住你想改什么就先点它。配置项里最常见的三个块是参数设置、字段映射、JSON 视图。参数设置就是节点本身的选项比如 LLM 节点要选模型、填提示词工具节点要填访问凭证。字段映射决定这个节点从上游拿哪些数据、往下游吐哪些数据。JSON 视图则把所有配置以纯文本形式展示出来方便复制、对比或批量修改。新手最容易在字段映射上卡住。比如上游节点输出了一个叫 article_text 的字段下游节点需要引用它时你会发现在映射框里选择比手打更靠谱。手打经常出现下划线写错、变量名拼错的问题选择器不会犯这种错。2.4 顶部工具栏与底部状态栏运行状态一眼看清编辑器顶部工具栏放的是全局操作运行、保存、测试、发布。底部状态栏容易被忽略但它透露的信息很关键。状态栏会显示当前环境是 Demo 还是 Production已经执行过多少次还有最近一轮的资源消耗。如果你发现某个流程越跑越慢先看状态栏的消耗数据而不是盲目改模型。我自己的习惯是每次打开编辑器先看底部状态栏确认当前处于哪个环境再开始动手。很多人改了半天配置最后发现改的是 Production 环境直接把半成品发布出去了。这个坑踩一次就够记一辈子。3. Agent 配置区不是填表单是定义行为边界3.1 系统提示词怎么写不要写成功能清单Agent 的行为很大程度由系统提示词决定但很多人把系统提示词当成功能清单来写。比如你要做客服要回答用户问题要礼貌要处理售后要推荐产品。这样写不是不行而是太弱模型会把它当成一堆并列的要求遇到复杂情况时不知道优先级是什么。更有效的写法是先定义你是谁再定义你工作的边界最后定义你输出的格式。一个参考结构是这样的你是一个跨境电商客服助手你的目标是在一次回复内解决用户的售后问题。除非用户明确要求否则不要主动推荐商品。所有回复控制在三句话以内并且最后必须给出一个可操作的后续步骤。这样写等于给模型划了一条跑道而不是给了一堆散落的规则。优先级、边界、输出格式都有了模型面对不同用户问题时行为会更稳定。还有个小技巧配置区改完提示词先别急着保存在测试面板里连续问几个不同类型的问题确认行为变化符合预期再保存。改提示词是最容易引入回归的操作没有测试就保存后面出了问题很难追溯是改哪句话引起的。3.2 模型选择与温度参数什么时候选推理型什么时候选快速型Antigravity 的模型配置区一般会提供多种模型可供选择性能取向不同。大体上可以分成两类推理能力强、但速度较慢响应快、但复杂推理能力一般。这不是越贵越好而是要看你的 Agent 具体在干什么。我整理了一个简单的选择参考使用场景推荐取向理由多步骤复杂任务、需要判断分支优先推理型每一步的决策质量直接影响后续流程常规问答、信息抽取均衡型即可任务简单不用过度消耗算力高并发客服、实时响应优先快速型用户体验取决于响应速度代码生成、逻辑推导优先推理型错误率比速度更重要温度参数很多人不理解其实它就是控制随机性的旋钮。温度越低模型每次都倾向于选概率最高的回答结果更稳定温度越高回答更随机、更有发散性。写分类判断、数据抽取这类任务建议把温度调低做头脑风暴、创意文案温度可以适当调高。拿做饭打比方温度低是严格按菜谱来温度高是允许厨师自由发挥没有绝对好坏只看你要什么。3.3 工具注册给 Agent 装手而不是装嘴一个只会聊天、不会干活的 Agent 价值很有限。工具配置区就是用来给 Agent 装手的。Antigravity 内置了一些常用工具比如网页搜索、代码执行、HTTP 请求。某些场景下你还需要接入自定义 API将外部服务封装成一个工具。这里有个非常关键的细节给工具写描述时要写这个工具是干什么的、适合什么场景而不是写实现细节。模型靠工具描述来决定是否调用、何时调用。描述写得太窄模型该用的时候想不到用写得太笼统模型又会在不该用的时候乱用。工具参数定义也同样重要。每个参数最好有清晰的名称和类型说明它接受什么格式的数据。我见过一个问题某个查询工具的入口参数叫 q描述写的是查询关键词。看起来没毛病但模型有时候会把用户的问题原封不动填进去导致一段很长的自然语言被当成关键词去搜索结果当然不理想。后来把参数描述改成简短的主题词不超过五个词从用户问题中提取核心实体调用准确率立刻上来了。4. 可视化工作流把思考链变成可调试的画布4.1 为什么用节点连线而不是纯代码其实在 Antigravity 出来之前不少团队是靠写代码调大模型 API 来搭 Agent 的。那套方式不是不可以而是有两个问题一是每次改流程都要重新部署反馈周期太长二是非工程背景的人完全没法参与讨论。可视化的节点连线直接把流程画出来谁都能看懂谁都能上手改。但可视化并不代表随便拖它本质上还是在描述一套程序逻辑。所以你得带着流程图思维去操作而不是把节点当成积木随便摆。我习惯先在草稿纸上画出大致的处理流程再进编辑器拖节点效率会高很多。4.2 连接线的数据流每个节点输入输出的 JSON 结构画布上每一条连线不是简单的谁接着谁它代表的是数据流动。节点之间传输的数据是结构化 JSON比如 { query: xxx, search_result: xxx }。上游节点的输出会成为下游节点的输入你可以在下游节点的配置里引用上游字段。举个例子搜索工具节点会输出一个 search_result 字段里面是网页摘要。后面接的 LLM 生成节点可以在提示词里这样引用请根据以下搜索结果回答问题{{search_result}}。这个双大括号引用是连接到上游字段的标准方式。这里有个常见的困惑为什么我引用了字段但运行时报错说找不到多半是上游节点名叫 front-page-search字段叫 result而你引用时写成了{{search_result}}。字段名和节点名是两回事引用字段时必须以实际输出的字段名为准。运行一次之后在节点输出面板里看一眼实际的 JSON 结构比凭记忆猜要靠谱得多。4.3 分支、循环与失败处理一次典型的多步任务拆解单线流程只能处理顺序执行的任务真实的业务需求几乎都有分支和异常。搭分支时你需要用到条件判断节点。它的工作方式是接收上游数据根据配置的条件路由到不同下游。举一个实际的客服工单场景。用户发来一条消息Agent 需要先判断用户是咨询、投诉还是售后。判断节点会输出三个分支分别连接到不同的处理流程咨询走自动回复投诉走加急工单售后走退换货流程。三个分支末端再汇聚到一个统一的结束节点。循环节点同样重要典型场景是多次抓取分页数据或者反复优化答案直到满足条件。使用循环节点时务必设置最大迭代次数不然模型可能陷入死循环白白消耗算力。失败处理是最容易被忽略的。每个工具调用都可能失败网络超时、API 返回错误、数据格式异常。打流程时最好给每个工具节点都接一个失败分支让 Agent 在出错时能给出备选方案而不是干巴巴地报错。4.4 子流程与模板复用做一个自己的起点当流程越搭越长画布会变得难以阅读。Antigravity 提供子流程功能可以把一坨节点打包成一个整体在主画布上变成一个独立的子流程节点。这就像写代码时的函数封装把常用的逻辑抽出来既能让主流程清晰也方便复用。我个人的建议是把你最常用的一套搜索 → 提取 → 生成流程存成子流程或模板。下次新建项目时直接从模板拉一个出来再针对项目需求做微调比每次从零开始拖节点省太多时间。打磨自己的模板库是这个编辑器里回报率最高的习惯。5. 调试控制台测试环节最容易被忽略的三件事5.1 从第一条测试消息开始你的 Agent 真的读懂了提示词吗编辑器通常自带一个测试面板可以在不发布的情况下直接对话调试。很多人上来就输入一个复杂问题看到结果不对就一脸茫然。调试的第一条消息应该足够简单简单到只是为了验证 Agent 有没有正确理解自己的角色。比如你刚写完一个客服 Agent 的系统提示词测试消息不要一上来就是我要投诉订单号 20240101 你们怎么这么慢。先从你好开始看 Agent 会不会自我介绍、会不会按提示词设定的语气回应。如果连最简单的问候都偏离了角色设定那不用怀疑问题出在提示词而不是流程上。5.2 展开中间步骤看模型到底走了哪条路测试面板一般会提供中间步骤展开功能。点开之后你能看到这一次对话中模型依次调用了哪些工具、每个工具返回了什么、最终答案是基于哪些数据生成的。这一步是排查问题最有力的工具。举一个真实遇到过的排查过程。我给一个 Agent 加了搜索工具但运行时发现它经常不调用搜索就直接回答。从中间步骤看模型把搜索工具当成可选而非必选因为我在提示词里写的是如果需要可以搜索这个措辞太软。改成针对任何涉及实时信息的问题必须先调用搜索工具再回答之后模型每次都规规矩矩先搜索再作答。如果当时不看中间步骤只会觉得模型笨永远发现不了措辞的问题。5.3 日志级别与资源消耗别等到发布后才发现爆 token调试控制台里的日志级别选项很多人从没动过默认情况下它只记录运行结果。把日志级别调到 Verbose 或详细模式你才能看到每一轮的 Token 消耗、每步调用的耗时。这个信息很重要因为有些流程开发时跑得很流畅一上线就频频超时或超预算就是因为开发阶段的短对话掩盖了长对话的消耗。在测试阶段就要养成习惯用一个接近真实长度的输入跑通全流程然后看总 Token 消耗。如果一次简单任务消耗高得离谱优先检查是不是模型中转了太多轮或者提示词里塞了太多不必要的上下文。这些资源消耗问题在编辑器里就能发现并优化等上线后再处理就被动了。6. 从编辑器到发布版本快照与运行环境衔接6.1 发布前必查的检查清单在点击发布按钮之前我建议先过一遍检查清单这张清单是我踩过几次坑之后总结出来的。第一系统提示词里有没有敏感信息。有人会直接把内部 API Key 或数据库地址写进系统提示词发布之后等于把这些东西暴露给了所有使用的人。第二工具节点有没有配置正确的访问凭证测试环境能跑通不代表生产环境也有同样的权限。第三每个工具节点是否都有失败分支不能只保证正常路径能跑通。第四环境变量是否正确区分了测试环境和正式环境别在正式环境里调用了测试环境的服务。第五流程中的循环节点是否有最大迭代限制防止极端情况下死循环烧钱。6.2 版本快照改崩了还能回得去编辑器的版本快照功能很容易被忽略但它是你敢大胆改配置的底气。每次做较大改动之前先创建一个快照。快照相当于这个 Agent 当前配置的存档点改坏了、改崩了随时可以回滚到上一个正常状态。我吃过一次亏当时连续改了提示词、工具参数、流程分支改完发现整个 Agent 行为完全跑偏却怎么都回不到之前的稳定版本。后来养成习惯任何一次涉及多个节点的修改先打快照再动手。这不是多此一举而是给自己留退路。特别是多人协作的项目你不知道其他人会不会也在改同一个 Agent定期打快照几乎等于买保险。6.3 权限与环境配置测试环境与正式环境要分开多人协作时编辑器还有权限管理功能。项目成员可以分成查看、编辑、管理几个角色。我的建议是核心生产 Agent 的管理权限只给少数人其他成员给编辑或查看权限就够了。团队里最怕的是所有人都能直接改生产配置改坏了也不知道是谁改的。环境配置上测试环境和正式环境的账号、变量、工具凭证都要分开维护。编辑器的环境切换功能可以把同一套流程部署到不同环境但环境变量要单独配置。你要是偷懒共用一套 API Key随时可能因为测试流量把生产账单刷爆或者反过来把测试数据写进生产库。这不是危言耸听是真有人这么干过。最后说一点个人体会。我在实际使用中发现编辑器真正难的不是某个按钮不会点而是思维方式的转换从写一段代码实现功能到定义行为边界并搭一条可验证的流程。前者关注实现细节后者关注行为预期和兜底方案。我建议你每次在编辑器里改完配置都先问自己三个问题这个 Agent 现在知道自己在干什么吗它遇到异常会怎么办我发布之后能不能快速回滚这三个问题过了基本就可以放心点发布按钮了。这篇对正在啃编辑器的你如果有帮助那就花二十分钟按上面的路径走一遍比反复看截图有效得多。