Gemini 3.7 Flash 的 Agent 任务怎么验收：多步执行、工具结果与最终状态

Agent 接口最容易让验收变成一句“模型返回了答案”。但 Gemini 的托管 Agent 会在 Linux sandbox 里推理、运行代码、管理文件，甚至访问网络；真正要验收的是这条执行链有没有按预期结束，工具结果有没有回到正确回合，以及权限边界是否仍然可控。

把 Agent 任务当成一条可观察的状态链验收：先确认使用的模型和 agent_config，再逐步记录工具调用与结果，最后只把明确的 model_output 和终态交给用户。

Gemini 3.7 Flash Agent 到底执行了什么

Google 的 Agents overview 把托管 Agent 描述为可配置的 Agent harness：一次 API 调用会提供 Linux sandbox，Agent 可以在其中推理、执行代码、管理文件和浏览网页。文档列出的 Antigravity agent 默认由 Gemini 3.7 Flash 驱动，也允许通过 agent_config 配置其他 Gemini 模型。

这决定了验收对象不是单一字符串，而是一组按时间排列的执行步骤。应用侧至少要能区分用户输入、模型思考、工具调用、工具结果和最终 model_output。如果只保存最后答案，出了问题就无法回答“工具是否真的执行过”以及“哪个结果影响了答案”。

先把多步任务拆成可检查的状态

在 Go 服务里，可以把每个事件归一成小型审计记录。这里的字段只描述验收需要的最小信息，不保存密钥和完整敏感输入。

type AgentStep struct {
    Kind   string // tool_call, tool_result, model_output
    Name   string
    Status string // running, succeeded, failed
    Ref    string
}

func acceptSteps(steps []AgentStep) error {
    if len(steps) == 0 {
        return fmt.Errorf("no agent steps")
    }
    toolCalls := map[string]bool{}
    for _, step := range steps {
        switch step.Kind {
        case "tool_call":
            if step.Ref == "" || step.Name == "" {
                return fmt.Errorf("invalid tool_call")
            }
            toolCalls[step.Ref] = true
        case "tool_result":
            if !toolCalls[step.Ref] {
                return fmt.Errorf("orphan tool_result: %s", step.Ref)
            }
            if step.Status == "failed" {
                return fmt.Errorf("tool failed: %s", step.Name)
            }
        case "model_output":
            if step.Status != "succeeded" {
                return fmt.Errorf("model output not final")
            }
        }
    }
    return nil
}

tool_result 必须能通过 Ref 找到前面的 tool_call，否则它只是孤立的外部数据。实际接入 SDK 时，Kind、Name 和 Ref 应由响应事件映射而来，不要让模型自己填一份“已成功”的验收 JSON。

工具结果返回后，为什么还不能马上判定成功

Gemini 文档将工具分为托管工具和自定义工具。Code Execution、URL Context 等托管工具在一次 API 调用内部完成；自定义 Function Calling 则需要应用执行函数，再把带有相同调用标识的结果回传给模型，模型可能据此继续发起下一次工具调用。

因此，tool_result 到达只说明一个阶段完成，不等于整个任务完成。验收逻辑要继续等待明确的 model_output，并检查没有未收口的工具调用：

func finalState(steps []AgentStep) (string, error) {
    pending := map[string]bool{}
    final := ""
    for _, step := range steps {
        if step.Kind == "tool_call" {
            pending[step.Ref] = true
        }
        if step.Kind == "tool_result" {
            delete(pending, step.Ref)
        }
        if step.Kind == "model_output" && step.Status == "succeeded" {
            final = "completed"
        }
    }
    if final == "" {
        return "", fmt.Errorf("missing model_output")
    }
    if len(pending) != 0 {
        return "", fmt.Errorf("pending tool calls: %d", len(pending))
    }
    return final, nil
}

sandbox、网络和凭据是上线前的硬边界

隔离环境不是“可以随便放权限”的理由。官方建议只连接可信的外部工具和 API，按最小权限配置服务账号或 API key，并优先使用短期凭据。托管 Agent 默认有出站网络能力，生产场景应使用 network allowlist 缩小可访问域名。

还有一个经常被忽略的事实：托管 Agent 目前属于 Public Preview，官方明确建议在用于敏感工作流前复核 Agent 的动作和输出。这个提醒应进入发布门禁，而不是只放在 README 里。

最小可行的验收顺序

1. 记录本次请求使用的模型、agent_config、工具清单和网络 allowlist。
2. 按事件顺序保存 tool_call、tool_result 与 model_output 的非敏感摘要。
3. 用调用引用配对每个工具结果，检查失败分支是否被显式处理。
4. 只有出现成功的 model_output 且不存在 pending tool calls，才写入 completed。
5. 对会改数据、访问外部系统或产生代码的结果安排人工复核，再进入业务动作。

常见问题

Agent 返回一段完整文字就算成功吗？

不算。至少要确认执行步骤收口、工具结果配对成功，并出现明确的最终输出状态。

托管 Agent 的 sandbox 可以访问任意网站吗？

默认出站网络能力较宽，生产任务应配置 network allowlist，只允许任务必须访问的域名。

为什么要保留工具调用引用？

因为自定义工具的结果必须回传到对应调用；没有引用就无法证明结果属于哪一轮，也无法可靠处理重试和失败。

Public Preview 的 Agent 能直接用于敏感流程吗？

不建议直接放行。应先复核 Agent 动作、输出、网络范围和凭据权限，再决定是否进入人工审批后的流程。

把“有答案”改成“可验收”

Gemini 3.7 Flash Agent 的价值在于把推理、代码执行、文件管理和工具协作串起来；工程风险也正来自这条长链。应用只要把 tool_call、tool_result、model_output 和 completed 分开记录，再加上网络与凭据门禁，就能把一次不可解释的模型回答变成可复查的任务结果。