技术思考问题1：通用工作智能体落地企业架构上最大的挑战是什么？

芒格模型：系统思维 + 安全边际

企业智能体的分水岭，不是多一个聊天框，而是能否把执行链关进可控边界。

[读者] 正在设计企业级智能体平台的后端工程师/架构师
[痛点] 需求从问答升级为跨系统执行，权限、状态、成本开始失控
[现在读] 谷歌云发布Gemini Agent，通用工作智能体进入企业主战场
[读完] 能设计一条可审计、可回滚、有安全边际的智能体执行链

[旧方案] 单聊天框 + 直接调模型 + 硬编码工具
    |
    v
[新需求] 跨应用、长任务、多模型、企业连接器
    |
    v
[冲突] 身份、状态、权限、执行治理没有统一层
    |
    v
[后果] 越权、丢状态、成本失控、审计断裂

我是老李，在深圳一家制造企业做智能体平台。2026年初，老板看到谷歌云在Gemini at Work 2026发布Gemini Agent，定位为“通用工作智能体”，一个提示框和一个API覆盖问答、知识工作、媒体生成和代码编写，托管在Gemini Enterprise应用里，能在后台跨应用和设备工作。老板只问了一句：我们能不能也做一个？

我们已有ERP、OA、供应商门户和数据仓库，各部门自己搭了聊天机器人。它们各自维护会话，硬编码服务账号，工具调用直接穿透到业务系统。平时问答没问题，一旦要求“帮我完成供应商准入”，问题就来了。

官方博客提到，该智能体目前支持Gemini和Claude模型，默认由AI选择最合适的模型，用户也可自行指定，并提供API供开发者集成。具体模型版本、可用区域和配额需按当前官方文档核验。我关心的不是它接了几个模型，而是它背后如何统一管理企业上下文、身份权限、工具调用与执行治理。

当提示框从问答入口变成业务执行入口，原来的“会话记忆+函数调用”还撑得住吗？

是继续给每个业务系统封装一个聊天框，还是抽出一层统一的执行治理平面？

如果继续按功能模块拼装，企业敢把采购审批、生产变更、客户数据导出交给它自动跑完吗？

01、故事

项目立项时，我拿到的任务是：把“采购申请到供应商准入”这条跨系统流程，用智能体跑通。验收标准很具体：用户给一个目标，智能体自动查ERP库存、比价、生成审批单、调OA提交、写审计日志，全程使用最小权限，敏感节点必须人工审批。

当前方案是V1：一个聊天机器人挂三个工具函数，模型直接决定调哪个。ERP查询用只读服务账号，OA提交用管理员账号。为了让演示顺利，我们甚至把工具调用超时设成30秒，重试三次。

第一周演示很成功。第二周接入真实供应商数据后，问题开始暴露：一次网络抖动让OA工单重复提交了三张；一次进程重启让任务状态全丢；月底账单显示模型调用成本超出预算四倍。

更麻烦的是审计。老板问“是谁批准了这家供应商”，我们只能翻聊天记录，找不到统一主体、授权链和工具执行证据。

那一刻我意识到，智能体不是“会聊天的工具集合”，而是一条业务执行链。模型越强，规划越自主，边界就必须越清晰。

一个提示框
一条执行链
不是多封装
而是先定界

02、问题

旧方案失效的根因不是模型不行，而是治理缺位。每个聊天框独立维护会话，工具直接拿服务账号全权限调用，长任务状态与进程绑定，模型路由写死，成本没有上限。

业务影响很快出现：审批不可追溯、敏感操作无审批、跨系统状态不一致、失败后无法补偿。技术上表现为：Token过期后任务中断、重试无幂等导致重复写入、审计日志缺主体、预算超限无告警。

要解决这些问题，先要定义可验证的完成标准。我们最后写下五条：第一，给定一个业务目标，智能体能在限定预算和权限内跨至少三个系统完成任务；第二，每次工具调用都有主体、授权范围、输入输出和审计记录；第三，超时或中断后任务可恢复，重复调用有幂等键；第四，敏感操作进入人工审批闸门；第五，失败可回滚或补偿。

这五条不是功能清单，而是安全边际。它们决定了自动化能走多远。

旧法已失效
新需跨系统
标准先写清
再谈自动化

03、原理

智能体的最小闭环是“目标→规划→工具→结果”，但企业级系统还要在中间插入“身份、权限、状态、审批、审计、预算”。模型负责规划，系统负责边界。

这里有一个反直觉判断：模型越强，越需要把决策和执行分离。因为模型可以生成任意计划，但企业不能让它任意执行。决策层可以自由探索，执行层必须经过策略校验。

另一个反直觉判断是：安全边际不是刹车，而是续航。没有权限、审计、预算和回滚，自动化只能停留在演示环境；加上这些边界，才敢让它进入生产流程。

对应到Gemini Agent这类产品，官方称其可接受目标而非仅指令，自行规划任务、使用技能与工具并连接企业内部系统。具体实现细节需按当前官方文档核验。我们能确定的是：只要它触碰企业系统，就必须回答“以谁的身份、在什么权限下、执行了什么、花了多少、失败了怎么办”。

模型管规划
系统管边界
决策与执行
分开才可控

04、架构

[输入] 企业目标 / 事件
    |
    v
[模块] 智能体编排层
    |
    v
[数据/状态] 上下文 / 身份 / 任务状态
    |
    v
[处理] 模型路由 → 工具调用 → 审批 → 沙箱执行
    |
    v
[输出] 业务结果 / 审计 / 成本

这条链的边界很清楚：编排层不直接执行业务逻辑，而是把模型输出转成受治理的工具调用。身份来自企业IdP，权限走策略引擎，状态外置到持久化存储，审批走人工闸门，工具在沙箱内执行，审计贯穿全程。

收益是可控、可追溯、可恢复。代价是复杂度上移：需要维护策略、状态、审计、预算和模型路由。适用条件是跨系统、长任务、敏感操作；如果只是单系统问答，这套架构可能过重。

模型路由是其中一环。官方提到默认由AI选择最合适的模型，用户也可指定。我们在架构上把它抽象成路由策略：按任务类型、数据敏感度、成本和可用区域选择模型，而不是写死在某段代码里。

输入到输出
治理在中间
边界即收益
代价是复杂

05、实战一次

先搭一个最小V1：单进程、标准库、无外部依赖。环境为Python 3.11，依赖仅标准库。目标是跑通“身份校验→预算检查→工具调用→审计记录→超时中断”。

核心实现如下：

import json
import time
import threading

class BudgetExceeded(Exception):
    pass

class PermissionDenied(Exception):
    pass

class TimeoutExceeded(Exception):
    pass

class Tool:
    def __init__(self, name, func, required_scope):
        self.name = name
        self.func = func
        self.required_scope = required_scope

class AuditLog:
    def __init__(self):
        self.records = []

    def write(self, **kw):
        rec = {'ts': time.time(), **kw}
        self.records.append(rec)
        print(json.dumps(rec, ensure_ascii=False))

class AgentRuntime:
    def __init__(self, identity, budget=1.0):
        self.identity = identity
        self.budget = budget
        self.spent = 0.0
        self.tools = {}
        self.audit = AuditLog()
        self.state = {}

    def register(self, tool):
        self.tools[tool.name] = tool

    def _check_scope(self, tool):
        if tool.required_scope not in self.identity['scopes']:
            raise PermissionDenied(
                f"{self.identity['sub']} lacks {tool.required_scope}"
            )

    def _charge(self, cost):
        if self.spent + cost > self.budget:
            raise BudgetExceeded(
                f"budget {self.budget}, spent {self.spent}, need {cost}"
            )
        self.spent += cost

    def call(self, tool_name, payload, timeout=3, cost=0.1):
        tool = self.tools[tool_name]
        self.audit.write(
            event='tool_call_start',
            tool=tool_name,
            sub=self.identity['sub'],
            payload=payload
        )
        self._check_scope(tool)
        self._charge(cost)
        result = {}

        def run():
            nonlocal result
            try:
                result = {'ok': True, 'data': tool.func(payload)}
            except Exception as e:
                result = {'ok': False, 'error': str(e)}

        t = threading.Thread(target=run)
        t.start()
        t.join(timeout)
        if t.is_alive():
            self.audit.write(
                event='tool_call_timeout',
                tool=tool_name,
                sub=self.identity['sub']
            )
            raise TimeoutExceeded(tool_name)
        self.audit.write(
            event='tool_call_end',
            tool=tool_name,
            sub=self.identity['sub'],
            result=result,
            spent=self.spent
        )
        return result

def erp_query(payload):
    return {'supplier': ['A', 'B'], 'payload': payload}

def oa_submit(payload):
    return {'ticket': 'OA-1001', 'payload': payload}

rt = AgentRuntime(
    identity={
        'sub': 'agent-procurement',
        'scopes': ['erp:read', 'oa:write']
    },
    budget=1.0
)
rt.register(Tool('erp.query', erp_query, 'erp:read'))
rt.register(Tool('oa.submit', oa_submit, 'oa:write'))

print(rt.call('erp.query', {'item': 'M8螺栓'}))
print(rt.call('oa.submit', {'supplier': 'A', 'item': 'M8螺栓'}))

启动方式：

python agent_runtime.py

请求模拟：智能体收到目标“为M8螺栓完成供应商准入”，规划出先查ERP再提交OA。

验证点：审计日志包含主体、工具名、输入、输出和累计花费；越权时抛PermissionDenied；超预算时抛BudgetExceeded；超时抛TimeoutExceeded。

未在当前环境实测，以下为预期结果。示例输出：

{"ts": 1770000000.0, "event": "tool_call_start", "tool": "erp.query", "sub": "agent-procurement", "payload": {"item": "M8螺栓"}}
{"ts": 1770000000.0, "event": "tool_call_end", "tool": "erp.query", "sub": "agent-procurement", "result": {"ok": true, "data": {"supplier": ["A", "B"], "payload": {"item": "M8螺栓"}}}, "spent": 0.1}

V1跑通了，但它留下四个问题：状态在进程内，重启即丢；模型路由写死；没有审批闸门；没有真正的沙箱隔离。

最小跑通链
审计留主体
预算设上限
先证再扩边

06、排查

第一个问题：长任务跑到一半重启，OA工单重复提交。现象是供应商收到三张相同审批单。怀疑是任务状态保存在内存。检查审计日志和state，发现tool_call_start之后没有tool_call_end，重启后state为空，同一业务单号再次进入。根因是执行状态与进程生命周期绑定，且没有幂等键。修复是把任务状态外置到持久化存储，并用业务单号做幂等键。

第二个问题：月底预算提前耗尽。现象是模型调用成本曲线陡增。怀疑是重试风暴。检查按工具聚合的审计日志，发现同一工具在超时后立即重试，没有退避，也没有预算预留。根因是重试策略与预算、幂等脱节。修复是指数退避、最大重试次数、预算预留。

错误尝试： 一开始我们把权限检查放进每个工具函数内部，让业务代码自己判断。为什么错？因为策略分散在多个工具实现里，任何一个工具都可能绕过检查；审计拿不到统一主体，权限变更要改多处代码。正确做法是把权限校验前移到编排层，工具只做业务动作。

现象引怀疑
证据定根因
错试需记录
修复要闭环

07、优化

基于第06章的证据，V2做四项改动。

第一，任务状态外置。根因是进程内存不可靠；修改为在每次工具调用前后写任务状态；新行为是重启后可恢复；验证方式是人为重启进程，检查任务从最后成功节点继续。

第二，引入幂等键。根因是重复提交；修改为每个业务动作带唯一幂等键；新行为是重复请求返回同一结果；验证方式是用同一幂等键调用两次OA提交，观察是否只生成一张工单。

第三，权限集中校验。根因是工具内散落权限判断；修改为编排层统一读取身份和策略；新行为是工具实现无法绕过；验证方式是构造缺少scope的身份，确认调用被拒绝。

第四，预算与重试联动。根因是重试不受预算约束；修改为预算预留、指数退避、最大重试；新行为是超预算前提前终止并告警；验证方式是模拟超时，观察重试间隔和预算变化。

这些改动没有虚构性能数据，只定义了可验证行为。它们共同构成安全边际：不是让智能体少做事，而是让它在越界前停下。

根因驱动改
幂等加退避
审批加沙箱
新行为可验

08、演进

[同一输入]
    |
    +--[V1] 进程内执行 / 上下文易丢 / 权限分散
    |
    +--[V2] 持久化编排 / 统一治理 / 审计完整
    |
[Trade-off]
得到可控与可追溯，失去部分低延迟与开发简单性；适用边界：跨系统、长任务、敏感操作

正确性上，V1依赖模型一次性规划，V2把执行拆成可校验步骤。稳定性上，V1怕重启和超时，V2有状态恢复和幂等。复杂度上，V2引入持久化、策略、审批和沙箱，开发和运维成本更高。成本上，V2增加预算控制和退避，减少失控调用。适用范围上，V2适合企业跨系统流程，V1只适合演示和低风险问答。

遗留问题是模型路由的可观测性和工具沙箱的隔离强度。官方Gemini Agent支持Gemini和Claude，默认由AI选模型，也允许指定，并提供API集成。具体配额、区域和治理能力需按当前官方文档核验。我们把模型路由做成可替换策略，避免绑定单一供应商。

同一输入下
两版不同路
取舍在边界
演进看遗留

09、洞见

9.1 模型越强，越要把决策和执行分开

反直觉判断：模型能力越强，规划越自主，越不能让它直接拥有执行权。决策层可以探索，执行层必须经过策略、审批和审计。否则能力越强，越权风险越大。

9.2 安全边际不是刹车，是续航

反直觉判断：最小权限、审批、沙箱、超时、预算这些约束，看起来降低自动化速度，实际决定自动化能否进入生产。没有安全边际，智能体只能停在演示环境。

9.3 统一上下文不是“记住更多”，而是“可解释地遗忘”

企业上下文包含会话、身份、任务状态、工具结果和审批记录。统一管理不等于全部塞进模型窗口，而是分层存储、按需注入、到期清理。否则上下文越大，污染和越权风险越高。

9.4 工具调用的治理粒度决定自动化上限

工具不能只是函数，还要带权限范围、幂等键、超时、成本、审批要求和审计字段。治理粒度越细，能开放的自动化范围越大。

洞见非口号
来自证据链
反直觉常在
判断可复用

10、系统落地

原来我们有的是三个独立聊天框、硬编码服务账号和分散的审计。本篇新增的是统一编排层、身份权限校验、任务状态外置、幂等键、预算控制和审计记录。

现在能做的事情很具体：用户给出“完成M8螺栓供应商准入”这样的目标，智能体在限定预算和权限内查ERP、生成审批单、调OA提交，并留下完整审计。敏感操作会停在审批闸门，超时会中断并可恢复。

还缺什么？缺真正的工具沙箱、细粒度数据脱敏、跨模型路由的统一观测，以及人工审批体验。下一步演进方向是：先把这条采购流程跑满一个季度，收集失败模式和审计缺口，再把自动化范围扩大到生产变更和客户数据导出。

Gemini Agent的发布说明企业级智能体正在从问答走向通用工作执行。官方博客链接为 https://cloud.google.com/blog/products/ai-machine-learning/welcome-to-gemini-at-work-2026/ ，其中模型支持、API能力和企业治理细节需按当前官方文档核验。我们的判断是：无论底层用Gemini、Claude还是其他模型，编排层和安全边际必须自己掌握。

原来各自跑
现在统一管
能做什么事
还缺什么环

11、小结

Q1 → 统一执行治理层，而不是再封装聊天框
Q2 → 身份、状态、权限、审批、审计、预算一个不能少
Q3 → 先从有验收标准的跨系统流程闭环验证
状态 → V1可跑通单进程受治理调用，V2补齐持久化与审批

本篇最终可交付的能力是：一个最小但完整的智能体执行链原型，以及一套判断企业级智能体是否可控的验收标准。它不是功能清单，而是安全边际。

三问有答案
状态可交付
能力有边界
继续向前走

12、作业

12.1 理解题：为什么说“模型越强，越需要把决策和执行分离”？

参考答案：模型负责生成计划和选择工具，但执行涉及企业权限、数据和成本。如果模型直接拥有执行权，越权、误操作和审计缺失的风险会随能力增强而放大。分离后，执行层可以做统一校验、审批和回滚。

12.2 实战题：为V1加入幂等键与预算预留，写出关键改动。

参考答案：在任务状态中增加idempotency_key字段；调用工具前先查该键是否已执行，已执行则直接返回历史结果；预算方面，调用前预留本次最大可能成本，成功后结算实际成本，失败则释放预留。

12.3 排障题：审计日志只有tool_call_start没有end，如何定位？

参考答案：先检查进程是否在工具执行期间重启或崩溃；再检查工具是否超时且未捕获；然后检查审计写入是否在异常路径被跳过。修复方向是状态外置、超时中断记录、异常统一落审计。

12.4 架构判断题：是否应该把权限检查放进每个工具实现里？

参考答案：不应该。权限检查应前移到编排层，由统一策略引擎基于身份、工具和上下文判断。工具实现只负责业务动作。这样策略集中、审计统一、避免绕过。

理解要到位
实战要动手
排障要证据
架构要判断

13、思考

回到最初的冲突：一个提示框背后，不是多封装一层聊天框，而是统一管理企业上下文、身份权限、工具调用与执行治理。系统思维要求把这些环节视为一条完整的业务执行链；安全边际要求在自动化之前明确最小权限、敏感操作审批、执行沙箱、审计追踪、超时重试与成本上限。

企业级智能体的竞争力，不在于“会做多少事”，而在于“能否在可控边界内持续、可靠地把事情做完”。先选一个有明确验收标准的跨系统流程做闭环验证，再逐步扩大自动化范围，这比一开始追求全能更接近生产。

系统思维先
安全边际后
可控才可靠
做完才算数