Google Gemini Agent 上线之后：企业常驻 Agent 要先过身份、目标规格、审批矩阵、审计归因与花费闸门

2026 年 10 月 8 日，Google Cloud 在 Gemini at Work 活动上宣布推出 Gemini agent：一个面向工作的统一 Agent，不只回答问题，还能从单一界面替用户把事做完。Google Cloud CEO Thomas Kurian 的表述很关键——可以给它 objectives（目标），而不只是 instructions（指令）；它会规划工作、调用自定义 skills/tools，并接入企业内系统。

Google CEO Sundar Pichai 在活动开场提到：Gemini 已有超过 10 亿月活，近 90% 的 Fortune 100 企业在工作中使用 Gemini Enterprise。因此 Google 选择 先做企业、后做消费端，以便先把安全、规模与性能这些更难的问题做扎实。

对做 Agent 平台、企业自动化和治理的工程师来说，真正要回答的不是“要不要跟进产品名”，而是：当组织里突然多出一个像同事一样常驻、有邮箱、能进群、能改系统的 Agent 时，身份怎么设、目标怎么写、副作用谁批、审计记在谁名下、花费怎么封顶。本文按上线顺序，把这些要求整理成七道闸门，并给出可直接改造的代码骨架。

1. 先把公开事实和工程推论分开

类别	内容	出处
公开事实	统一 Agent：从单一界面不仅回答，还能替用户完成工作；可被赋予目标而非仅指令；会规划、用 skills/tools、连接内部系统	TechCrunch（Sarah Perez，2026-10-08）、Google 博客
公开事实	默认选择最合适的模型，用户可覆盖；第三方模型从 Anthropic Claude 起步；计划扩展到开源与私有模型	TechCrunch
公开事实	可连接 Workspace、Microsoft 365、Slack、Jira、Confluence、Git、BigQuery、Databricks、Postgres、Snowflake 等；可安全连接网络内外的 MCP server	TechCrunch
公开事实	Tasks inbox：可见思考过程、子 Agent 委派、skills 加载、代码与进度	TechCrunch
公开事实	Agent 拥有独立 Workspace 账号（自有邮箱与上下文），像同事；知道团队、时区、审批人、日历；可通过 @、邮件、分享、群聊调用；审计轨迹归因于 Agent，而非个人	TechCrunch
公开事实	入口覆盖 iOS/Android、Windows/Mac、CLI、Workspace、M365、ServiceNow、Slack	TechCrunch
公开事实	早期测试：On、Shopify、PayPal；企业客户举例含 BNP Paribas、Bradesco、Merck、Orange Spain、Santee Cooper、SOMPO、Ulta Beauty、Wesfarmers 等	TechCrunch
公开事实	灵活花费：多模型编排、智能路由、实时 spend caps	TechCrunch
公开事实	Gemini >1B MAU；约 90% Fortune 100 使用 Gemini Enterprise；先企业后消费，以解决安全/规模/性能难题	TechCrunch（引用 Pichai）
工程推论	自建或接入同类“常驻工作 Agent”时，必须把身份、目标规格、审批、白名单、花费与审计做成平台能力，而不是靠提示词约定	作者建议

下文所有阈值、字段名、等级划分，凡未注明出处的，都是示例值，请按自己的合规与风险等级调整。

2. 为什么“像同事”比“像聊天框”更难

聊天助手出错，最坏是说错话；常驻 Agent 出错，失败面会多出几类：

身份混淆：动作记在某位员工名下，离职、审计、追责全部失真；
目标漂移：只给了步骤清单，没有成功/中止条件，中途失败不知道该停还是该换方案；
副作用失控：Agent 能发邮件、改工单、提 PR、写库，没有审批矩阵就会“全自动踩雷”；
工具面过大：MCP 与连接器一开，等于把半个企业系统交给模型；
花费失控：多模型编排 + 子 Agent 委派，账单可能按任务指数放大；
不可观测：操作员看不到思考、委派与进度，只能事后翻日志。

所以工程原则可以写成一句：Agent 是主体（有身份、有预算、有审计），人是委托人与审批人（有目标、有确认权）。

身份与审计归因：Agent 是主体，不是某人的替身

3. 闸门一：Agent 身份——独立账号，绝不“借用”个人身份

公开报道里，Gemini Agent 会拿到自己的 Workspace 账号：独立邮箱与上下文，像另一位同事。自建同类能力时，建议把身份拆成三个字段，而不是塞进一个 user_id：

字段（示例）	含义	常见错误
`agent_id`	Agent 主体，审计 actor	用个人邮箱发信
`principal_id`	委托人（谁发起目标）	把委托人写成 actor
`approver_id`	当前副作用的审批人	审批人缺省为发起人

# identity.py —— 示例：Agent 身份与会话上下文
from dataclasses import dataclass
from datetime import datetime, timezone

@dataclass(frozen=True)
class AgentIdentity:
    agent_id: str          # 例：agent.ops-scheduler
    email: str             # 例：ops-scheduler@example.com（示例域名）
    display_name: str
    team_id: str
    timezone: str          # 例：Asia/Shanghai
    # 禁止：复用某位员工的 OAuth token 当作 Agent 身份

@dataclass
class RunContext:
    agent: AgentIdentity
    principal_id: str      # 委托人
    objective_id: str
    started_at: datetime

def audit_actor(ctx: RunContext) -> dict:
    # 审计主体永远是 Agent；委托人单独落库
    return {
        "actor_type": "agent",
        "actor_id": ctx.agent.agent_id,
        "principal_id": ctx.principal_id,
        "ts": datetime.now(timezone.utc).isoformat(),
    }

落地检查清单（示例）：

IdP / Workspace / AD 里为 Agent 建服务主体，可吊销、可轮换密钥；
日历、通讯录、审批人查询走 Agent 自己的凭证，不借用委托人的；
所有外发动作的 From / Author 显示 Agent 名称，正文可附“受某某委托”，但元数据不伪造人；
人员离职流程不自动删除 Agent；Agent 退役走独立的生命周期。

4. 闸门二：目标规格——给目标，不给不可检验的步骤串

Kurian 强调的 “objectives, not just instructions” 对工程的含义是：平台要有一份可序列化的目标规格，而不是只把自然语言塞进对话历史。

# objective.py —— 示例：目标规格
from dataclasses import dataclass, field
from typing import Literal

SideEffect = Literal["read", "draft", "external", "privileged"]

@dataclass
class ObjectiveSpec:
    goal: str                          # 一句话目标
    success_criteria: list[str]        # 可检验的成功条件
    abort_conditions: list[str]        # 必须停下的条件
    max_tool_calls: int = 40           # 示例上限
    max_tokens: int = 200_000          # 示例上限
    allowed_side_effects: set[SideEffect] = field(
        default_factory=lambda: {"read", "draft"}
    )
    deadline: str | None = None        # ISO8601，示例

def validate_objective(spec: ObjectiveSpec) -> None:
    if not spec.goal.strip():
        raise ValueError("goal 不能为空")
    if not spec.success_criteria:
        raise ValueError("至少一条可检验的成功条件")
    if not spec.abort_conditions:
        raise ValueError("至少一条中止条件（超时、超预算、审批拒绝等）")

写目标时常用的反模式：

只写“帮我处理一下上周的客户投诉”——没有成功标准；
把成功标准写成“尽量好”——无法自动判定完成；
没有 abort：Agent 会在工具报错后无限换路径，最终烧光预算。

建议在 Tasks 收件箱里并排展示原始目标与当前判定状态（进行中 / 已满足成功条件 / 已触发中止），方便操作员接管。

目标规格与审批矩阵

5. 闸门三：审批矩阵——副作用按等级，确认框由宿主渲染

连接器一旦打通 Workspace、Slack、Jira、Git、数据仓库，Agent 就具备真实世界副作用。公开产品会把“像同事一样协作”做成体验；工程侧必须配套审批矩阵。

等级（示例）	典型动作	默认策略
L0 只读	检索、汇总、只读看板	自动执行 + 留痕
L1 草稿	写文档草稿、创建未提交变更	自动执行 + 强留痕
L2 外发	发邮件、建工单、开 PR、改日历	指定审批人确认
L3 资金/权限	付款、授权变更、生产配置	双人审批 / 变更窗口

# approval.py —— 示例：审批矩阵与确认令牌
from dataclasses import dataclass
from enum import Enum
import secrets

class EffectLevel(str, Enum):
    L0_READ = "L0"
    L1_DRAFT = "L1"
    L2_EXTERNAL = "L2"
    L3_PRIVILEGED = "L3"

APPROVAL_MATRIX = {
    EffectLevel.L0_READ: {"mode": "auto"},
    EffectLevel.L1_DRAFT: {"mode": "auto_audit"},
    EffectLevel.L2_EXTERNAL: {"mode": "single_approver"},
    EffectLevel.L3_PRIVILEGED: {"mode": "dual_control"},
}

@dataclass
class PendingAction:
    action_id: str
    tool_name: str
    level: EffectLevel
    payload_hash: str
    confirm_token: str
    approver_ids: list[str]

def gate_action(tool_name: str, level: EffectLevel, approvers: list[str]) -> PendingAction | None:
    mode = APPROVAL_MATRIX[level]["mode"]
    if mode == "auto" or mode == "auto_audit":
        return None  # 直接执行，但仍写审计
    if not approvers:
        raise PermissionError(f"{tool_name} 需要审批人，但未配置")
    return PendingAction(
        action_id=secrets.token_hex(8),
        tool_name=tool_name,
        level=level,
        payload_hash="…",  # 对规范化参数做哈希，防篡改
        confirm_token=secrets.token_urlsafe(24),  # 一次有效
        approver_ids=approvers,
    )

注意三点：

确认框由宿主渲染，不要让模型自己“生成一个同意按钮”；
确认令牌绑定 payload_hash，防止“先展示 innocuous 参数、执行时偷换”；
审批人默认来自目标规格或组织目录（汇报线 / 变更经理），不要静默回退到委托人。

6. 闸门四：Tasks 收件箱——操作员要看见思考、委派与进度

TechCrunch 描述的 tasks inbox 能看到：思考过程、子 Agent 委派、skills 加载、代码与进度。自建时，这不是“好看的 UI”，而是运行时控制面：

每个 Run 有稳定 run_id；
事件流至少包含：thought / tool_call / tool_result / subagent_spawn / skill_load / progress / awaiting_approval / abort；
操作员可 Pause / Abort / Takeover（接管后 Agent 停止写侧效应）；
支持导出为活动账本（JSONL），供事后审计与评测回放。

# inbox_events.py —— 示例：活动账本事件
from dataclasses import dataclass, asdict
from typing import Any
import json, time

@dataclass
class InboxEvent:
    run_id: str
    agent_id: str
    kind: str
    summary: str
    detail: dict[str, Any]
    ts_ms: int

def emit(path: str, ev: InboxEvent) -> None:
    with open(path, "a", encoding="utf-8") as f:
        f.write(json.dumps(asdict(ev), ensure_ascii=False) + "\n")

# 示例写入
# emit("runs/run_123.jsonl", InboxEvent(
#     run_id="run_123", agent_id="agent.ops-scheduler",
#     kind="awaiting_approval", summary="拟发送客户邮件（L2）",
#     detail={"tool": "gmail.send", "approver": "u_456"},
#     ts_ms=int(time.time() * 1000),
# ))

若子 Agent 被委派，父 Run 的收件箱应能下钻到子 Run，并在父级汇总进度百分比（示例：按成功条件 checklist 计数，而不是按 token 估）。

7. 闸门五：工具与 MCP 白名单——连接器要缩权

公开事实列出了很长的连接器名单，并支持网络内外的 MCP server。工程上这意味着：默认拒绝，按环境放行。

# tool_policy.py —— 示例：连接器 / MCP 白名单
ALLOWED_CONNECTORS = {
    "prod": {"workspace.readonly", "jira.issue.read", "bigquery.query"},
    "staging": {"workspace", "m365", "slack", "jira", "git", "bigquery", "postgres"},
}

ALLOWED_MCP = {
    "prod": {"mcp://internal/hr-policy@1"},           # 示例 URI
    "staging": {"mcp://internal/hr-policy@1", "mcp://internal/dev-tools@2"},
}

def authorize_tool(env: str, tool: str, scopes: set[str]) -> None:
    allowed = ALLOWED_CONNECTORS.get(env, set())
    if tool not in allowed and not any(tool.startswith(a + ".") for a in allowed):
        raise PermissionError(f"{env} 未允许工具 {tool}")
    # scopes 必须是声明集的子集（示例策略）
    # …

def authorize_mcp(env: str, server_uri: str) -> None:
    if server_uri not in ALLOWED_MCP.get(env, set()):
        raise PermissionError(f"{env} 未允许 MCP {server_uri}")

实践建议（示例）：

生产环境默认只开只读连接器；写权限按目标规格临时提升，目标结束即收回；
外网 MCP 与内网 MCP 分池，凭证与网络策略隔离；
每个工具声明 effect_level，与审批矩阵联动；
新增连接器走变更单，而不是在提示词里“告诉 Agent 多了一个工具”。

8. 闸门六：多模型路由与花费帽——编排要可记账

Gemini Agent 默认自动选模，用户可覆盖；第三方从 Claude 起步，并规划开源与私有模型；同时提供多模型编排、智能路由与实时 spend caps。自建时至少要有：

能力（示例）	说明
路由策略	按任务类型选小/大模型；敏感数据可钉死到私有模型
覆盖入口	操作员可强制模型，但写入审计
实时花费帽	按 Agent、按团队、按 Run 三级；超限降级或暂停
记账维度	`agent_id` 为主，附带 `principal_id` 与 `objective_id`

# spend_gate.py —— 示例：实时花费闸门
from dataclasses import dataclass

@dataclass
class SpendCap:
    per_run_usd: float = 5.0       # 示例
    per_agent_day_usd: float = 50.0  # 示例
    per_team_day_usd: float = 500.0  # 示例

@dataclass
class SpendState:
    run_usd: float = 0.0
    agent_day_usd: float = 0.0
    team_day_usd: float = 0.0

def check_spend(cap: SpendCap, st: SpendState, next_cost: float) -> str:
    if st.run_usd + next_cost > cap.per_run_usd:
        return "pause_run"       # 暂停当前 Run，等审批加预算
    if st.agent_day_usd + next_cost > cap.per_agent_day_usd:
        return "degrade_model"   # 示例：降到更便宜模型
    if st.team_day_usd + next_cost > cap.per_team_day_usd:
        return "block_team"
    return "allow"

不要只在账单日看总额：子 Agent 委派会把一次目标拆成多路并行，没有 per-run cap 就会在午后突然打满团队配额。

工具白名单、花费闸门与任务收件箱

9. 闸门七：审计归因——记在 Agent 名下，且可导出

公开报道明确：动作产生的审计轨迹归因于 Agent，而不是某个人。这对合规很友好，但要求你们的日志 schema 一开始就分得清：

{
  "event_id": "evt_01J…",
  "actor_type": "agent",
  "actor_id": "agent.ops-scheduler",
  "principal_id": "user_123",
  "approver_id": "user_456",
  "objective_id": "obj_789",
  "run_id": "run_123",
  "tool": "jira.issue.transition",
  "effect_level": "L2",
  "decision": "approved",
  "request_hash": "sha256:…",
  "result": "ok"
}

审计最低要求（示例）：

谁做的：actor_id = Agent；
谁让做的：principal_id；
谁批准的：副作用等级 ≥ L2 时必填；
做什么：工具名 + 规范化参数哈希（必要时存加密原文）；
结果与回滚点：失败也要记，便于回放。

若把 Agent 动作记成员工操作，后续的权限审查、SOC 告警、法务取证都会被污染——这是比“Hallucination”更贵的一类事故。

10. 上线清单（可直接贴进变更单）

按环境推进时，建议按下面顺序勾选（全部为示例流程）：

身份：Agent 服务账号、密钥轮换、显示名与邮箱就绪；
目标模板：至少 3 类业务目标有 success / abort 字段；
审批矩阵：L0–L3 映射到具体工具；确认 UI 由宿主渲染；
收件箱：事件流可中止、可导出 JSONL；
白名单：生产连接器默认只读；MCP 分池；
花费：per-run / per-agent-day / per-team-day 三级帽；超限有降级路径；
审计：抽检 20 条日志，确认 actor 不是个人；
演练：故意触发 L2 外发与花费超限，确认会停而不是“尽量继续”。

11. 和“再做一个聊天机器人”的差别

维度	聊天助手	常驻工作 Agent
身份	通常落在用户会话	独立主体 + 委托人
输入	指令 / 问答	目标规格（可检验）
副作用	少，或每次人工点	审批矩阵 + 令牌
工具面	少量插件	连接器 + MCP 白名单
成本	按对话	多模型编排 + 实时帽
审计	对话日志	归因于 Agent 的活动账本

Google 选择先企业后消费，公开理由是先解决安全、规模与性能。落到你们自己的平台，这三句话可以翻译成：先有身份与审计，再有目标与审批，最后才是更聪明的路由与更多的工具。

12. 参考资料

Sarah Perez，TechCrunch：《Google brings agentic AI to Gemini, starting with businesses》（2026-10-08 11:18 AM PDT）
Google 官方博客：《Google Cloud introduces the Gemini agent.》（Gemini at Work，2026-10-08）

（正文不展开商业条款与报价；接入以各云厂商当前控制台与文档为准。）

本文同步发布于 CSDN：https://blog.csdn.net/qq_29737119/article/details/167372975