企业团队讨论智能体时，真正棘手的问题通常不是“模型能不能回答”，而是“它能否在受控条件下访问数据、调用系统、记住上下文，并在故障时被定位和纠正”。Google 推出的 Gemini Enterprise Agent Ready（GEAR）学习路径，正是围绕这条从原型到生产的链路组织：智能体基础、多智能体编排、MCP 工具连接、记忆与状态、领域技能，以及 AgentOps。
这套路径的价值不只在于课程或技能徽章，更在于它明确了生产级智能体必须补齐的工程边界。
把“会聊天”拆成可交付的系统能力
一个可上线的智能体，至少包含四层，而不是单个提示词：
- 决策与执行循环：模型根据目标选择下一步，调用工具后读取结果，再决定继续、交付或升级给人工。
- 受控的数据与工具层：访问一方和三方数据时，必须限定身份、权限、可访问字段和可执行动作。
- 状态与记忆层：会话状态保存当前任务进度；长期记忆保存经过明确授权、适合复用的用户偏好或业务事实。
- 运行与治理层：日志、指标、追踪、评测、CI/CD 和安全策略共同决定系统是否可运维。
GEAR 中的 Agent Fundamentals、Enterprise Agents and Use Cases，以及 Human-Centered AI，覆盖了从决策模型到业务 KPI 和人工协作的前半段。它提醒团队：不要把“自主”理解为无约束。越接近付款、库存调整、客户沟通等高影响动作，审批、回滚和人工接管就越重要。
多智能体不是角色堆叠，而是流程拆分
多智能体适合处理职责清晰、输入输出能结构化定义的工作流。例如零售补货场景可以划分为：数据检索智能体读取库存和销量，分析智能体产生补货建议，执行智能体创建草稿订单，人工审批后才真正提交。
关键设计原则是让每个角色都有窄职责和明确契约：
- 将自然语言结果收敛为 JSON Schema 或等价的结构化输出。
- 工具调用使用最小权限令牌，禁止模型直接持有全局数据库凭据。
- 将“生成建议”和“产生外部副作用”分离，尤其是写库、发邮件、下单等操作。
- 为跨系统任务设置幂等键，避免重试时重复执行。
Google 的多智能体编排和 Gemini Enterprise 相关课程强调跨一方、三方数据源的协作。落到项目中，先画出任务状态图通常比先定义十个智能体角色更有效：谁读取、谁判断、谁执行、谁审批、失败后回到哪里，都应当可见。
用 MCP 连接外部系统时，安全边界要先于便利性
MCP（Model Context Protocol）让模型通过标准化工具接口访问外部能力，例如汇率、工单、知识库或数据库。它降低了集成门槛，但不会自动解决授权问题。
下面是一个可以直接运行的 Python 示例。它模拟“汇率查询工具 + 会话状态 + 审批门槛”：金额超过阈值时，智能体只能提出建议，不能执行兑换。示例不依赖特定模型 SDK；接入 ADK 或其他框架时，可将 decide() 替换为模型的结构化工具调用结果。
运行前保存为 agent_demo.py，然后执行 python agent_demo.py：
from dataclasses import dataclass, field
from decimal import Decimal
RATES = {("USD", "CNY"): Decimal("7.20")}
@dataclass
class SessionState:
user_id: str
approved_limit_cny: Decimal
history: list[str] = field(default_factory=list)
def get_exchange_rate(base: str, quote: str) -> Decimal:
"""模拟 MCP 工具：生产环境应在服务端做身份验证、审计和限流。"""
try:
return RATES[(base, quote)]
except KeyError as exc:
raise ValueError(f"不支持的货币对: {base}/{quote}") from exc
def decide(state: SessionState, amount_usd: Decimal) -> dict:
rate = get_exchange_rate("USD", "CNY")
amount_cny = (amount_usd * rate).quantize(Decimal("0.01"))
state.history.append(f"查询 USD/CNY={rate}; 金额={amount_cny} CNY")
if amount_cny > state.approved_limit_cny:
return {
"action": "request_human_approval",
"amount_cny": str(amount_cny),
"reason": "金额超过当前会话的自动执行额度",
}
return {
"action": "create_exchange_draft",
"amount_cny": str(amount_cny),
"idempotency_key": f"{state.user_id}-usd-{amount_usd}",
}
if __name__ == "__main__":
state = SessionState(user_id="user-42", approved_limit_cny=Decimal("5000"))
result = decide(state, Decimal("1000"))
print(result)
print(state.history)
示例中的 approved_limit_cny 是策略输入，不应由模型自行决定。真实 MCP 服务还应验证调用方身份、限制工具参数、脱敏输出，并记录每次读取和写入操作的审计事件。
记忆、技能与可观测性要一起设计
课程路径中的 Memory and State、Create Agent Skills、AgentOps 对应三个常被原型忽略的问题。
状态不是记忆。 状态服务于当前任务，例如订单号、审批阶段和最近一次工具结果；它通常有生命周期。记忆则用于跨会话个性化，例如用户偏好的报告格式。将完整聊天记录无限写入“记忆”会带来成本、隐私和错误固化风险。
技能不是一段长提示词。 可复用技能应封装领域规则、输入结构、允许调用的工具、输出格式和评测样本。例如“生成营销素材”技能可以产出文案草稿和媒体需求，但不应自行发布到外部渠道。
AgentOps 不是上线后的补丁。 每次执行至少应记录任务 ID、模型版本、提示词版本、工具调用、耗时、错误类型和最终状态。对关键动作还应记录审批者与策略版本。这样才能回答“为什么它调用了这个工具”“某次升级后成功率是否下降”“哪类请求最常触发人工接管”。
可以这样定义一个最低限度的部署检查清单：
- [ ] 为每个工具定义输入、输出、超时、重试和权限范围。
- [ ] 将写操作置于审批、策略检查或明确的自动化额度之下。
- [ ] 将会话状态与长期记忆分开，并规定保留和删除策略。
- [ ] 用结构化输出校验模型结果，拒绝不符合 Schema 的动作请求。
- [ ] 为端到端流程准备正常、工具失败、权限拒绝和重复请求的评测集。
- [ ] 在监控面板中跟踪延迟、成本、工具错误率、任务完成率和人工接管率。
选择学习路径，也选择一个可验证的业务问题
GEAR 将入门、无代码原型、Gemini Enterprise 应用、多智能体工作流、ADK 工程化、MCP 和 AgentOps 串成连续路径。对工程团队而言，最务实的起点不是泛泛地做一个“万能助手”，而是选择一个有明确 KPI、可限制权限、可人工复核的流程：例如研究摘要、库存建议或工单分流。
先用小范围数据验证效果，再增加工具、记忆和自动执行权限。智能体进入生产的门槛，不是它能完成多少演示，而是团队能否清楚说明它能做什么、不能做什么，以及出错时如何停止、追踪和恢复。