企业官网建设流程全解析

如果你跟我一样，是从第一篇一路刷到第七篇的，大概率已经对 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 现在知道自己在干什么吗？它遇到异常会怎么办？我发布之后能不能快速回滚？这三个问题过了，基本就可以放心点发布按钮了。这篇对正在啃编辑器的你如果有帮助，那就花二十分钟按上面的路径走一遍，比反复看截图有效得多。