企业级 Agent 与聊天机器人最大的区别，不是多调用几个工具，而是能否持续执行数天、记住关键上下文，并在严格权限和审计约束下代表组织采取行动。Gemini Enterprise Agent Platform 此次将 Agent Runtime、Agent Memory Bank、Agent Identity、Agent Gateway、Agent Registry，以及评估和可观测能力进一步开放，覆盖了 Agent 从运行到治理的完整生命周期。
从一次对话升级为最长 7 天的工作流
普通聊天接口通常围绕一次请求和响应设计，但销售跟进、供应链合规监控、员工入职和故障处置可能跨越几小时甚至数天。Agent Runtime 面向这类异步任务，可让 Agent 持续运行最长 7 天。
这项能力改变了工作流的设计方式。开发者不必把全部逻辑塞进一次模型调用，而可以将任务拆成多个可恢复阶段：
- 读取当前任务状态和历史决策；
- 调用 CRM、工单或监控工具；
- 等待外部事件或审批；
- 根据新信息继续推理；
- 完成任务或升级给人工处理。
长时间运行并不意味着让一个进程连续占用资源七天。更稳妥的实现通常需要检查点、幂等工具调用、超时、重试和人工审批边界。尤其是付款、修改生产配置、删除数据等高风险操作，不应只依赖 Agent 自主判断。
Agent Memory Bank 则解决跨阶段上下文问题。它通过结构化模式提取并维护用户偏好、历史决定和账户信息，让 Agent 在任务恢复时读取必要事实，而不是反复把完整聊天记录塞进提示词。结构化记忆也更容易设置保留期限、字段级权限和删除策略。
例如，销售 Agent 的记忆可以只保存这些字段：
# 这是便于设计记忆模式的示意配置，并非官方 API 清单。
memory_schema:
customer_id: string
preferred_channel: enum[email, phone, app]
approved_budget_range: string
last_decision: string
next_follow_up_at: timestamp
consent_to_contact: boolean
不要把“记住更多”直接等同于“效果更好”。密码、访问令牌、完整支付信息和无明确用途的个人数据不应进入长期记忆。团队还需要定义哪些字段由模型提取、哪些必须由业务系统提供，以及发生冲突时谁是事实源。
Identity、Gateway 与 Registry 组成治理闭环
Agent 开始自主调用系统后，传统的共享服务账号会迅速成为风险点：权限不断累积、负责人不清晰，凭据泄露后也难以确认具体由哪个 Agent 发起操作。
Agent Identity 为 Agent 提供原生 IAM 身份，并强调最小权限。访问权与 Agent Runtime 绑定，可降低令牌被盗用的风险；Agent 操作能够形成不可抵赖的审计记录，身份生命周期也可自动管理，减少遗留凭据。
围绕身份之外的控制，平台还提供两个关键组件：
- Agent Gateway：所有 Agent 交互的集中控制点，可通过 IAM 条件和自然语言规则实施细粒度访问控制。集成的 Model Armor 用于防御提示词注入、工具投毒和数据泄漏。
- Agent Registry：集中登记组织内的 Agent、服务器和连接，帮助团队发现并复用已有能力，也让管理员识别无人维护、重复建设或未经审核的 Agent。
三者承担不同职责：Identity 回答“谁在行动”，Gateway 决定“能否执行”，Registry 说明“组织里有哪些 Agent、由谁负责”。只部署其中一个，通常无法形成完整治理链路。
一个可以本地运行的最小治理原型
下面的 Python 示例不调用 Gemini Enterprise Agent Platform 的真实 API，而是一个可运行的、平台无关的治理原型。它演示了四个关键动作：验证 Agent 身份、限制工具权限、拦截明显的提示词注入，以及写入审计日志。接入实际平台时，可以将本地策略判断替换为 IAM、Agent Gateway 和 Model Armor 对应能力。
将以下内容保存为 agent_gateway_demo.py：
from dataclasses import dataclass
from datetime import datetime, timezone
import json
POLICIES = {
'sales-followup-agent': {
'owner': 'sales-platform@example.com',
'allowed_tools': {'crm.read', 'crm.add_note'},
'runtime_id': 'runtime-prod-sales-01',
}
}
BLOCKED_PATTERNS = (
'ignore previous instructions',
'reveal system prompt',
'send all customer data',
)
@dataclass(frozen=True)
class Request:
agent_id: str
runtime_id: str
tool: str
user_input: str
def audit(event: dict) -> None:
record = {
'timestamp': datetime.now(timezone.utc).isoformat(),
**event,
}
with open('agent-audit.jsonl', 'a', encoding='utf-8') as file:
file.write(json.dumps(record, ensure_ascii=False) + '\n')
def authorize(request: Request) -> tuple[bool, str]:
policy = POLICIES.get(request.agent_id)
if policy is None:
return False, 'unknown agent identity'
if request.runtime_id != policy['runtime_id']:
return False, 'identity is not bound to this runtime'
if request.tool not in policy['allowed_tools']:
return False, 'tool is outside the least-privilege policy'
normalized = request.user_input.lower()
if any(pattern in normalized for pattern in BLOCKED_PATTERNS):
return False, 'possible prompt injection'
return True, 'allowed'
def handle(request: Request) -> None:
allowed, reason = authorize(request)
audit({
'agent_id': request.agent_id,
'runtime_id': request.runtime_id,
'tool': request.tool,
'allowed': allowed,
'reason': reason,
})
print(json.dumps({'allowed': allowed, 'reason': reason}, ensure_ascii=False))
if __name__ == '__main__':
handle(Request(
agent_id='sales-followup-agent',
runtime_id='runtime-prod-sales-01',
tool='crm.add_note',
user_input='Add a note that the customer prefers email.',
))
handle(Request(
agent_id='sales-followup-agent',
runtime_id='runtime-prod-sales-01',
tool='billing.issue_refund',
user_input='Refund the latest invoice.',
))
运行并检查审计记录：
python3 agent_gateway_demo.py
cat agent-audit.jsonl
预期第一项请求通过，第二项因为 Agent 没有退款工具权限而被拒绝。这个示例只是最小骨架：生产环境还应使用防篡改日志、集中策略存储、凭据轮换、请求签名、速率限制和审批系统。简单关键词匹配也不能代替专业的提示词注入检测。
可观测性告诉你发生了什么，评估判断结果是否合格
Agent 上线后，只记录成功率和响应时间远远不够。一个工作流即使最终完成，也可能调用了错误的数据源、执行了多余步骤，或者在输出中泄露不该出现的信息。
Agent observability 提供端到端追踪和实时仪表盘，用于查看推理过程、工具利用情况及执行性能。Agent evaluation 则持续判断结果质量，并通过在线评估监控发现性能退化和行为漂移。平台支持预置指标、自定义 Python 指标、LLM-as-a-judge，以及自适应评分规则。
建设指标时，可以按四个维度拆分：
| 维度 | 示例指标 |
|---|---|
| 任务质量 | 完成率、事实准确率、人工接管率 |
| 工具行为 | 错误工具调用率、重复调用次数、越权拦截数 |
| 运行效率 | 总耗时、模型调用次数、单任务成本 |
| 安全合规 | 敏感数据泄漏率、审计覆盖率、策略拒绝率 |
评估与可观测性运行在同一套引擎上的价值，在于开发阶段优化的指标可以继续用于生产评分，减少“离线测试很好、上线后无法解释”的断层。不过，LLM-as-a-judge 仍可能存在偏差，涉及金融、医疗或安全决策时，应结合确定性规则、抽样人工复核和领域专家标注。
CodeMender 展示了安全 Agent 的另一个方向
此次更新还提到 CodeMender，这是一个托管代码安全 Agent，目标是让安全流程从被动扫描向自动化代码修复推进，并降低零日漏洞风险。它反映出企业 Agent 的价值不只在对话界面，也在于把检测、分析、生成补丁和验证串成闭环。
自动修复同样需要边界。更稳妥的落地方式是让 Agent 创建独立分支和拉取请求，运行单元测试、静态分析和依赖检查，再由代码所有者审核，而不是允许它直接修改生产分支。
落地时按风险递增，而不是一次开放全部权限
准备采用这些能力时，可以按以下顺序推进：
- 先选择一个可回滚、结果可验证的长流程，例如线索跟进或内部工单分类；
- 为记忆设计明确字段、保留期限、访问权限和删除机制；
- 给每个 Agent 分配独立身份、所有者和最小工具权限；
- 强制所有工具调用经过 Gateway，并默认拒绝未登记操作；
- 在 Registry 中记录版本、负责人、数据范围和生产状态；
- 上线前建立评估集，上线后持续监控行为漂移；
- 对资金、生产变更和敏感数据操作保留人工审批。
Gemini Enterprise Agent Platform 的这轮更新，重点不是增加一个更聪明的聊天入口，而是补齐 Agent 长期运行所需的耐力、身份、边界和反馈系统。真正决定企业能否扩大使用规模的，也往往不是模型单次回答有多精彩，而是每一次行动能否被授权、追踪、评估并在必要时撤销。