AGW 特点

最近更新：2026-09-25

• 1: 自定义 Agent
• 2: Agentflow
• 3: 多 Agent 上下文复用
• 4: 图片输入
• 5: 记忆：个人偏好与项目知识
• 6: Plan 与 Execute 模式
• 7: JSON Schema 结构化响应
• 8: 工具审批
• 9: 文件浏览与 Git 变更审查
• 10: 多端客户端
• 11: 第三方账号登录

1 - 自定义 Agent

最近更新：2026-09-25

为任务定义自己的 Agent

在 AGW 中，你可以把模型、指令和工具组合成一个可复用的 Agent。它根据任务和上下文作出判断，选择可用工具执行操作，再根据结果继续处理。

例如，创建一个“文档审查助手”，让它阅读材料、判断哪些地方难懂，并给出修改建议。需要直接修改文件时，再为它配置相应工具和权限。

可以自定义什么

你可以为材料整理、代码解释和结果审查分别创建 Agent，在 Chat 中按任务选择，也可以把它们放进 Agentflow，作为流程中的执行步骤。

开始使用

1. 准备可用的 Model Provider，在 Agents 中创建自定义 Agent。
2. 选择模型，写清职责和输出要求，例如“审查文档，按原文、问题、建议改写列出结果”。
3. 按需添加工具、Skills 或配置好的集成连接；读写文件时，确认 Project 工作目录。
4. 保存并启用 Agent，在 Chat 中用一小段材料验证回复，检查工具调用与实际结果。

从单个 Agent 到固定流程

单个 Agent 可以在职责范围内判断如何完成任务。当任务要求每次都经过明确的步骤，例如“整理后必须审查，审查后必须人工确认”，可以用 Agentflow 编排这些步骤。

Agent 的操作范围取决于实际配置的工具与权限。指令本身不会授予文件或外部服务的访问权；模型的判断和执行结果也需要验证。

创建自定义 Agent · 配置 Tools 与 Skills

2 - Agentflow

最近更新：2026-09-25

把确定的步骤编排成流程

Agentflow 是 Agent Workflow（Agent 工作流）。Agent 负责判断与执行，Agentflow 负责编排路由、执行预先确定的步骤。 你在画布上连接节点，定义先做什么、结果交给谁，以及何时需要人工确认。

例如，材料整理 Agent 判断哪些信息值得保留，审查 Agent 检查遗漏和表述问题；Agentflow 则安排“先整理、再审查、最后人工确认”的执行顺序。

flowchart LR
    I["Input：输入材料"] --> A["Agent：整理材料"]
    A --> B["Agent：审查结果"]
    B --> H["Human Gate：人工确认"]
    H --> O["Output：输出结果"]

管理步骤之间的路由

需要判断内容含义、生成文字或调用工具的工作交给 Agent；步骤之间的连接和分支规则在 Agentflow 中配置。这样可以直接查看流程是否包含必要的审查与确认环节。

示例 1：Coding，从实施到审查与提交

代码任务通常有一条明确的处理顺序：先实施，再检查；发现问题就返工，确认完成后再提交。把这些步骤放进 Agentflow，可以让不同 Agent 在同一个 Project 工作区中接力，由人决定是否进入下一阶段。

这条流程中的职责分配是：

1. Coding：使用 Codex 完成实现，修改当前工作区中的代码。
2. Checkpoint 与 Clear Messages：标记恢复边界，并清除传给下游的上游消息，让审查节点按自己的指令检查工作区中的 diff。
3. Code Review：使用 Claude Code 审查改动，给出问题与建议，再经过一个 Checkpoint。
4. Human Gate：由人判断是否还需要修改。需要返工时返回 Coding，完成后进入 Commit Agent。
5. Commit Agent：按已确认的要求执行 Git 提交。

开始前，需要在运行环境中配置好 Codex、Claude Code 和 Git，并确认各节点访问同一个 Project 工作区。为实施、审查和提交节点分别写清职责，先用一项小改动验证完整路径，再测试返工路径。

返工应通过 Human Gate 的人工回复和 If / Else If 条件表达：把 Human Step Mode 设为 Input，由人在 Response 中回复，例如约定“继续修改”返回 Coding、“完成”进入提交。Approval 模式只提供 Reject 和 Approve 两个按钮，不收集文字回复，条件分支读不到人工反馈。Input 模式的 Interrupt 和 Approval 模式的 Reject 都会停止流程，不会自动进入返工分支。 循环必须有明确的退出路径。

Agentflow 固定职责、顺序和人工决定的位置；测试是否通过、审查问题是否解决、最终 diff 是否符合预期，仍需要逐项核对。Checkpoint 的恢复条件见 Agentflow 使用指南。

示例 2：从小红书笔记中提取地点位置

旅游规划应用可以把“导入一篇笔记，在地图上展示地点”拆成三个数据处理步骤。Agentflow 串起处理过程，最后把地点数据交给业务系统，由前端负责地图展示。

开始前，需自行准备并配置示例使用的 Skill、高德地图 MCP 及其所需账号或凭据，确认执行节点可以调用它们。这些是示例依赖，不能仅凭创建 Agentflow 就获得相应服务能力。

先用一篇地点明确的笔记验证：是否成功读取内容，提取的地点是否来自原文，POI 是否匹配到正确城市和地址。同名地点、地址不完整或搜索无结果时，需要补充信息或人工核对，不能把候选坐标直接当作确定结果。

这里的分工很直接：工具负责获取笔记和查询位置，模型负责理解文本并提取地点，Agentflow 负责按顺序传递结果；地图展示仍由业务 UI 完成。

开始使用

1. 先准备并单独验证需要的 Agent，例如材料整理和文档审查。
2. 打开 Agentflows 编辑器，连接 Input、两个 Agent 节点、Human Gate 和 Output。
3. 为每个 Agent 节点写清任务，在 Human Gate 的 Human Step Mode 中选择 Approval，并填写确认提示。
4. 保存后在 Chat 中选择该 Agentflow，输入一段材料。Chat 会在当前回合中实时显示每个节点收到的输入，据此检查节点执行顺序、人工确认和最终输出。
5. 基础路径通过后，再添加条件分支或并行处理，并验证各条路径。

确定的是流程规则

预先确定步骤，不意味着模型每次都会给出相同答案。Agent 仍会根据输入作出判断；条件分支也会根据运行时结果选择路径。在 Human Gate 中选择 Reject 或 Interrupt 时，流程会停止。

Agentflow 还支持 Handoff 和 Magentic 等动态协作编排。若每一步都必须执行，应使用明确的顺序连线；若任务需要动态交接或规划，再选择相应编排块。

查看 Agentflow 使用指南 · 了解自定义 Agent

3 - 多 Agent 上下文复用

最近更新：2026-09-25

让不同 Agent 接力

分析需求、编写代码和审查结果可以交给不同 Agent。在同一个 Project 的同一个会话中切换目标时，AGW 会把其他目标新增的公开文字提供给接手的 Agent，减少反复复制背景和解释进度的工作。

例如，先让 Coding 完成修改，再切换到 Review，让它结合已有讨论审查结果；发现问题后，还可以切回 Coding 继续处理。

flowchart LR
    A["Coding：完成修改并说明结果"] --> B["同一会话的公开文字"]
    B --> C["Review：结合背景审查"]
    C --> D["切回 Coding：继续处理反馈"]

开始使用

1. 准备两个可运行的 Agent，例如 Coding 和 Review。
2. 在 Chat 中选择 Project，使用 Coding 开始会话。
3. 等待当前回合结束，在同一会话中切换到 Review，说明接下来要做什么。
4. 检查回复是否接上之前的讨论；重要约束可以在新消息中再次强调。

交接时说明下一步

切换 Agent 后，可以发送：“请根据上面的修改说明检查遗漏，只列出需要修正的问题。”接手的 Agent 会得到可复用的公开文字，但仍需要知道这一次的任务是什么。

重要的文件路径、验收条件和结论可以在交接消息中简要重述。若需要长期跨会话保留项目约定，可使用项目记忆。

复用范围

复用的是会话中的公开文字，不包括私有推理、工具调用协议或外部工具的全部内部状态；被中断或失败的回合中未完成的消息也不会交接。交接内容最多 32,000 个字符，较早内容可能不在本次交接范围内；需要处理的文件仍须在接手 Agent 的工作环境中可访问。新建会话不会自动继承另一个会话的讨论。

查看 Chat 使用指南；为不同用途配置外部 Agent。

4 - 图片输入

最近更新：2026-09-25

用图片补充文字

遇到界面问题、设计稿或图表时，可以直接把图片附在消息中，让 Agent 结合图片和文字理解任务。例如，附上错误截图并说明操作步骤，或让支持视觉的模型检查页面布局。

把问题说具体

例如，附上页面截图后可以问：“这张图中保存按钮被遮住了，请指出可能的布局问题，并说明还需要哪些信息。”比较两张图时，注明哪张是预期效果、哪张是当前页面。这样 Agent 更容易围绕同一个问题回答。

如果希望修改代码，还需要提供对应项目及文件访问能力；一张截图本身只提供视觉信息。

开始使用

1. 选择支持图片理解的模型和执行目标。
2. 在 Chat 中添加图片：Web 和 Desktop 把图片粘贴到输入框，Mobile 从相册选择。然后写明希望 Agent 关注的部分。
3. 确认附件后发送，检查回复是否正确理解了图片内容。

flowchart LR
    A["图片 + 文字问题"] --> B["Chat 消息"]
    B --> C["支持图片的模型 / 外部运行时"]
    C --> D["结合图片作答"]

图片能否被理解，取决于所选模型及外部运行时的支持情况；成功添加附件不代表所有模型都能识别图片。截图中的文字过小或内容不清晰时，补充关键文字和具体问题通常更有效。

查看 Chat 使用指南。

5 - 记忆：个人偏好与项目知识

最近更新：2026-09-25

保留值得长期使用的信息

对话可以结束，但工作习惯和项目知识往往需要继续保留。AGW 提供两类 Memory，让 Agent 在后续工作中使用已保存的信息。

为 Agent 或 Project 配置相应的 Memory 能力后，可以让 Agent 保存需要复用的信息，并在后续会话中检查或更新。记忆需要明确维护，不等于自动永久保存和注入全部聊天记录。User Memory 按用户隔离；Project Memory 的范围还取决于项目及所选存储方式，共用工作目录的文件型记忆也会共用。External Agent（Claude Code、Codex、Pi）只会读到已有的 User Memory（最多 50 条）作为上下文，没有记忆工具，不能保存或更新记忆；在 Agent 或 Project 上配置的 Project Memory 对它们不生效。

Project Memory 的两种存储模式

Project Memory 提供 Database 和 Project Workspace (Primary directory: .agw/memory) 两种存储方式，默认使用 Project Workspace。两者都让 Agent 使用同一组记忆工具来保存、查找、读取和更新项目知识，区别在于内容保存在哪里、如何共享及备份。

Database：由 AGW 集中保存

选择 Database 后，记忆内容保存在 AGW 当前配置的数据库中。它仍以文件名组织内容，但不会在项目工作目录中生成对应的记忆文件；Agent 通过 Project Memory 工具读取这些记录。

记忆按 Project ID 区分。同一个 Project 中使用数据库模式的 Agent 可以复用已有记忆；即使另一个 Project 指向同一个工作目录，也不会因此共用这份数据库记忆。修改主工作目录不会改变数据库记忆所属的 Project。

这种方式适合希望统一备份和管理数据的部署。备份时应按 AGW 数据备份流程保留数据库及所需的加密密钥；只复制代码目录不会带走数据库记忆。在多执行节点部署中，共享数据库也意味着这些节点可以访问同一份项目记忆，仍须通过项目访问权限检查。

Project Workspace：保存为项目目录中的文件

选择 Project Workspace (Primary directory: .agw/memory) 后，记忆保存在实际执行主机的主工作目录中。例如，Project 的 Workspace 为 /work/demo，记忆目录就是：

/work/demo/
└── .agw/
    └── memory/
        ├── coding-conventions.md
        ├── coding-conventions_description.md
        └── memories.md

上例中，coding-conventions.md 是记忆正文，coding-conventions_description.md 是保存时提供的可选说明，memories.md 是 AGW 维护的记忆索引。目录固定在主工作目录下，不会随 Files 界面选择的附加目录而改变。

这种方式方便直接查看文件，也可以自行决定是否将记忆纳入 Git 或项目文件备份。AGW 不会自动提交这些文件；备份和迁移时要确认没有遗漏隐藏目录。通过记忆工具写入或删除内容会同步维护索引；直接修改文件后，索引不一定随之更新，因此日常维护优先使用记忆工具。

两个 Project 如果指向同一个实际工作目录，会共用其中的 .agw/memory/，即使它们的 Project ID 不同。修改 Workspace 后，Agent 会使用新位置下的记忆，原目录里的文件不会自动搬过去。在 Docker 中，应持久化挂载工作目录；在多节点部署中，各执行节点需要看到同一份目录内容，仅有相同的路径字符串并不足够。

flowchart TD
    A["Project Memory 工具"] --> B{"Storage"}
    B -->|"Database"| C["AGW 数据库：按 Project ID 保存"]
    B -->|"Project Workspace"| D["主工作目录/.agw/memory"]

如何配置与验证

前提：已有可运行的自定义 Agent 和 Project；文件系统模式还需要执行主机能够读写主工作目录。

1. 打开 Agent 或 Project 的 Tools 配置，选中 Project Memory ToolBlock。
2. 在卡片展开后的 Storage 中选择 Database 或 Project Workspace (Primary directory: .agw/memory)，保存配置。希望项目内统一使用时，优先在 Project 中配置。
3. 在该 Project 的新回合中，让 Agent 保存一条明确的项目约定，例如：“将项目统一使用 UTC 的约定保存到 time-conventions.md，并添加简短说明。”写入操作仍受模式与审批设置约束。
4. 新建同一 Project 下的会话，使用具有相应记忆能力且存储模式一致的 Agent，让它列出并读取这条记忆。应能读到之前保存的内容。
5. 文件系统模式可同时检查 .agw/memory/ 中的文件；数据库模式不会在那里生成文件，应通过记忆工具验证。

两种模式是独立的数据来源，切换 Storage 不会自动复制、合并或删除另一种模式中的记忆。需要迁移时，先备份原存储，读取要保留的正文和说明，再切换模式并通过记忆工具重新写入，最后核对内容。修改配置后使用新回合验证，已经运行的回合仍使用开始时的配置。

Agent 如何使用已保存的记忆

Project Memory 会向模型提供记忆索引，再由 Agent 按需读取相关正文。当前自动生成的索引最多包含 50 条，更多记忆仍可通过列表和搜索工具查找；并不是每次请求都会发送全部记忆正文。

建议每份记忆围绕一个主题，使用清楚的文件名和简短说明。约定变化后更新原条目，过期信息及时删除，避免多份互相矛盾的说明影响后续任务。User Memory 则始终保存在数据库中，按用户隔离，不受这里的 Storage 选项影响。

实现与参考

• Project Memory 存储选择
• 记忆工具与索引
• 备份与升级

6 - Plan 与 Execute 模式

最近更新：2026-09-25

先想清楚，再动手

准备修改代码或执行复杂任务时，可以先让 Agent 分析现状和提出方案，再决定是否进入执行阶段。在自定义 Agent 或 Project 上配置 Mode ToolBlock 后，自定义 Agent 支持 Plan 与 Execute 两种工作模式；配置在 Project 上时，该 Project 中运行的自定义 Agent 都会获得这项能力。

一个文档修改的例子

先在 Plan 中要求：“阅读文档，指出术语不清和缺少示例的地方，先给修改建议。”查看方案并确认范围后，再进入 Execute，让 Agent 按方案修改文件。完成后检查差异，确认原有事实和限制被保留。

能否读取或修改文件仍取决于配置的工具。只切换模式，不会自动添加缺少的文件能力。

开始使用

1. 在自定义 Agent 或 Project 的 Tools 中配置 Mode ToolBlock 和任务所需工具。
2. 新回合默认处于 Execute。在 Chat 输入框点击 +，选择 Plan mode，输入框中出现 Plan 标记后，再要求 Agent 分析问题。
3. Agent 提出的方案显示为 Plan 卡片，可以复制。确认方案后点击 Plan 标记上的 × 回到 Execute；Agent 请求切换模式时，在界面中回应确认。
4. 检查实际改动和执行结果，必要时回到 Plan 继续讨论。

flowchart LR
    A["Plan：分析与方案"] --> B["用户确认切换"]
    B --> C["Execute：执行任务"]
    C --> D["检查结果"]
    D --> A

Plan 限制由工具的声明和执行检查决定，不能仅靠提示词保证。Execute 也不等于自动批准所有操作：工作模式决定哪些工具能用，审批设置决定调用时是否需要你确认。外部 Agent 使用各自支持的模式与权限能力，不能直接假设与自定义 Agent 完全一致。

了解工具审批 · 配置 Tools 与 Skills

7 - JSON Schema 结构化响应

最近更新：2026-09-25

让回复可以被程序读取

Agent 默认返回 Markdown 文本，适合阅读，却不便于程序提取字段。在 Agent 上配置 Response Schema 后，最终回复会按你提供的 JSON Schema 返回一个 JSON 对象，Job、Agentflow 和调用 API 的程序可以直接读取其中的字段。

例如，审查文档的 Agent 可以返回 issues 数组，每一项包含 original、problem 和 suggestion；定时运行时把结果写入工单系统，无需再从整段文字里查找内容。

配置内容

Response Schema 是 Agent 创建和编辑对话框中的一个 Tab，内容为一个 JSON Schema 对象：

{"type":"object","properties":{"answer":{"type":"string"}},"required":["answer"]}

保存时的校验规则：

推荐使用 JSON Schema draft-07。Anthropic 模型要求 Schema 写明 type 为 object、properties 为对象、required 为数组；全部字段都可选时写成 "required": []。使用 Anthropic Provider 的自定义 Agent 缺少这三项时，会在发出模型请求前报错。

支持范围

AGW 把 Schema 交给模型或 CLI，由它们按 Schema 生成结果；AGW 本身不逐项校验字段是否符合 Schema。自定义 Agent 开启 Generate Turn Summary 时，AGW 要求本轮最后一条完整回复中恰好有一个有效的 JSON 对象或数组，否则该回合报错结束，保留原有的执行记录。标记为 JSON 的 Result 内容无法解析时，Chat 显示 “Invalid structured result: expected one JSON object or array.”。

开始使用

1. 打开 Agents，编辑一个 Agent，切换到 Response Schema。
2. 粘贴 JSON Schema 对象，确认没有出现校验错误后保存。
3. 在 Chat 中运行一个小任务，检查最终结果是否为预期的 JSON。
4. 确认结构稳定后，把该 Agent 用于 Job 或 Agentflow 步骤。

flowchart LR
    A["Agent 配置 Response Schema"] --> B["回合执行"]
    B --> C["模型或 CLI 按 Schema 产生结果"]
    C --> D["Chat 按 JSON 显示 Result"]
    C --> E["Job、Agentflow 与 API 读取字段"]

自定义 Agent 同时开启“Generate Turn Summary”时，AGW 从本轮最后一条完整回复中提取这份 JSON，作为本轮的 Result，不再调用 Summary Model Provider；Chat 把这条 Result 按 JSON 原样显示，不经过 Markdown 渲染。没有开启时，模型仍按 Schema 返回 JSON 文本，但它只是一条普通回复，按 Markdown 显示，也不产生 Result，因此 Conversation Settings 中的 Only Stream Turn Result 对它不生效。Claude Code 和 Codex 每个回合都会产生 Result。已选择的 Summary Model Provider 会保留，关闭 Schema 后继续生效。

Schema 只用于描述结果结构，不会被当作代码执行，也不会自动请求 $ref 指向的远程地址。字段能否被正确填写取决于所选模型的能力和指令写法，结构正确的 JSON 仍需要核对内容。

配置自定义 Agent · 了解外部 Agent 的差异

8 - 工具审批

最近更新：2026-09-25

在操作前确认

Agent 调用工具时，AGW 可以根据权限设置请求你的确认。你可以先查看工具名称和参数，再决定是否继续，适合需要检查文件修改或命令执行的任务。

普通只读工具通常不需要执行审批。工具的权限声明决定是否需要审批，不是根据名称或命令看起来是否安全来判断。

怎样选择权限模式

第一次使用某项写入工具时，可以选择 Always ask，逐次查看它实际提交的参数。需要在同一会话重复相同操作时，Allow same arguments 可以复用已经确认且参数匹配的授权；参数改变后不能沿用这份授权。

选择 Full access 前，应先确认 Agent 的工具范围和工作目录。它减少普通工具调用的确认步骤，但任务结果仍需要核对。

开始使用

1. 选择支持审批的 Agent，并在 Chat 中选择合适的权限模式。
2. 发起任务；出现审批请求时，检查工具、参数与目标路径。
3. 同意后继续执行，或拒绝该调用并补充你的要求。
4. 检查工具结果，确认实际操作符合预期。

flowchart TD
    A["Agent 请求调用工具"] --> B["检查模式与权限"]
    B --> C["需要人工确认"]
    C --> D["同意：继续调用"]
    C --> E["拒绝：把结果交回 Agent"]

Full access 不会跳过 Plan 的工具限制，也不会替你回答用户输入问题或工作流中的 HumanGate。Claude Code 支持原生工具审批桥接；当前 Codex 和 Pi 接入仅支持 Full access。权限下拉框始终列出三种模式，目标不支持的模式显示为不可选，并在下方说明原因。

在 Conversation Settings 中打开 Only Stream Turn Result 后，External Agent 和开启 Generate Turn Summary 的自定义 Agent 遇到需要人工确认的工具审批或提问时会被直接拒绝，界面不显示这些请求。Full access 以及已有授权的自动批准不受影响。需要逐次审批时，应关闭这个开关。

查看外部 Agent 的权限差异 · 了解工作流人工审批

9 - 文件浏览与 Git 变更审查

最近更新：2026-09-25

在对话旁边检查 Agent 的修改

Agent 修改代码后，需要确认它改了哪些文件、每处改动是否符合预期。在 Chat 工作区切换到 Files，可以浏览 Project 工作目录中的文件、查看 Git 变更，并把需要调整的地方写成行评论交给 Agent，整个过程无需另开编辑器或终端。

查看变更

打开文件树顶部的 Diff 开关后，文件树只显示有 Git 变更的文件，并分为 Staged 和 Unstaged 两组。一个文件同时包含已暂存和未暂存的改动时，会在两组中各出现一次。文件名旁的字母表示变更类型：A 新增、M 修改、D 删除、U 未跟踪。

选中文件后，右侧左右对照显示改动前后的内容。Staged 分组对比 HEAD → Staged，Unstaged 分组对比 Staged → Working Tree。关闭 Diff 开关后，文件树显示完整目录，右侧显示文件的当前内容。

Reset to HEAD 和 Delete 直接修改磁盘上的文件，界面中无法撤销，执行前应确认没有需要保留的改动。

用行评论交给 Agent 修改

在文件内容或 diff 中，把鼠标移到某一行，点击行号右侧出现的 + 按钮即可写评论，按 Ctrl/Shift+Enter 提交，按 Esc 取消。已有评论的行不再显示这个按钮；双击评论可以修改，点击评论旁的删除按钮可以删除。Diff 视图的左右两侧可以分别评论改动前和改动后的内容。

写好的评论会暂时保存，Chat 输入框上方显示待发送的评论数量，例如 “2 code comments”。切回 Chat 写下总体要求并发送后，每条评论的文件路径、行号、评论所在一侧（改动前或改动后）和所在分组会随这条消息一起交给 Agent。Server 接受这次执行后，已发送的评论会从待发送列表中移除；点击数量旁的 × 可以放弃全部待发送评论。

例如，Agent 完成一次重构后，打开 Diff 查看 Unstaged 分组：在新增的重试逻辑处评论“重试次数改为读取配置项”，在另一处评论“这个分支缺少错误日志”，然后在 Chat 中发送“请按评论修改，完成后说明每处改动”。审查通过的文件可以先 Stage，Agent 下一次修改这些文件时，新改动会出现在 Unstaged 分组中，便于区分已审查和待审查的内容。

flowchart LR
    A["Agent 修改文件"] --> B["Files：打开 Diff 审查"]
    B --> C["为需要调整的行添加评论"]
    C --> D["Chat：随消息发送评论"]
    D --> A
    B --> E["审查通过的文件：Stage"]

开始使用

1. 选择一个工作目录位于 Git 仓库中的 Project。不在 Git 仓库中的目录也能浏览文件，但没有变更视图和 Git 操作。
2. 在 Chat 工作区点击 Files。Project 配置了附加目录时，用文件树顶部的下拉框选择要浏览的目录。
3. 打开 Diff 开关，在 Staged 或 Unstaged 分组中选择文件，检查改动。
4. 为需要调整的行添加评论，切回 Chat 发送消息，再回到 Files 检查 Agent 的新改动。

适用范围

• 文件树、diff 和 Git 操作只作用于当前选择的目录。切换浏览目录不会改变 Agent 的默认工作目录，Agent 仍从主工作目录开始工作。
• Files 页面不创建提交，也不切换分支；需要这些操作时，可以交给 Agent，或在终端中完成。
• 待发送的评论只保存在当前页面中，切换 Project 或刷新页面后会清空。
• Mobile 可以浏览文件、查看 diff，并重置或删除文件；Stage、Unstage 以及把行评论发送给 Agent 在 Web 和 Desktop 中使用。

配置 Project 的工作目录；查看 Chat 使用指南。

10 - 多端客户端

最近更新：2026-09-25

在合适的设备上继续工作

AGW 提供 Web、Desktop 和 Mobile 客户端。连接同一个 Server 并使用相应身份后，可以访问自己有权限的项目和服务端保存的会话记录，按场景选择设备。

同一服务与不同服务的区别

在另一台设备上继续查看工作时，先连接同一个 Server，再选择同一个 Project 和会话。服务端保存的历史可以继续查看；尚未保存的实时输出可能需要等待写入或重新连接后确认。

不同 Server 分别保存自己的配置和记录。切换 Server 后看不到原项目时，先确认地址和身份，而不要立即重新创建项目。

开始使用

1. 完成 Server 初始化，确保设备能够访问服务地址。
2. Web 使用管理员密码或第三方账号登录。Desktop 使用 API Key 连接；Server 配置了身份提供商时，也可以点击 Sign in with … 用第三方账号登录，由 Server 签发 API Key。Mobile 手动填写 API Key，或用 Import Web configuration 粘贴 Web Settings 中 Copy config 复制的连接配置。
3. 确认 Server 和 Project，打开已有会话或创建新会话。
4. 检查历史记录和执行状态，避免因设备切换重复发起同一任务。会话列表中的图标显示 Running、Last turn failed 或 Last turn interrupted。

任务在实际执行主机上运行，手机或浏览器连接不会把执行环境搬到当前设备。Desktop Full 包含 Server，Desktop Client 连接已有 Server；Mobile 当前提供源码运行方式。不同客户端的布局与管理入口有所差异。

查看客户端连接方法 · 安装与配置 Server

11 - 第三方账号登录

最近更新：2026-09-23

用已有账号进入自己的工作区

部署者在 Server 上启用身份提供商后，登录页会出现“Continue with …”按钮。你用组织账号（例如 Keycloak、Microsoft Entra ID、Google）或 OAuth2 服务（例如 GitHub）完成验证，就能进入 AGW，不需要再记一个管理员密码。

第一次用某个账号登录时，AGW 会为它创建一个独立的本地用户，并准备好默认 Project。此后 Agent、Project、对话记录、集成连接和 API Key 都归这个用户所有，其他用户看不到。管理员账号保持不变。

登录方式对照

身份提供商未配置时，管理员密码和 API Key 继续可用。Mobile 目前使用 API Key 连接。

开始使用

1. 请部署者在 Server 上启用身份提供商，并在提供商侧登记 AGW 的回调地址。
2. Web：打开 Server 地址，在登录页选择对应的账号按钮，完成验证后回到原来要访问的页面。
3. Desktop：在 Server 配置中选择“Sign in with …”，系统浏览器打开后完成验证，再回到 Desktop 窗口。
4. 检查 Project 列表是否为该账号的数据；Desktop 的 Server 配置中会出现“Sign out”按钮。

flowchart LR
    A["登录页选择账号"] --> B["身份提供商验证"]
    B --> C["Server 校验并确定本地用户"]
    C --> D["Web：写入会话 Cookie"]
    C --> E["Desktop：一次性代码换取 API Key"]

Desktop 使用系统浏览器完成验证，Server 通过 agw-desktop://auth/complete 把一次性代码交回 Desktop，Desktop 再用自己保存的校验值向 Server 换取 API Key。该代码两分钟内有效且只能使用一次，API Key 保存在系统凭据存储中。在 Desktop 中退出登录会撤销这个 API Key。

适用范围

同一个人在不同提供商下的账号是两个独立用户，AGW 按提供商签发者和账号标识判断身份，不按邮箱合并。当前不提供角色、管理员授权范围和 API Key 权限范围的设置；第三方账号登录得到的是普通用户身份。

停用某个提供商会阻止新的登录和尚未完成的 Desktop 换取，已经签发的 Cookie 和 API Key 需要单独处理。远程部署需要 HTTPS 地址。

配置身份提供商 · 连接 Web、Desktop 与 Mobile