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

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

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

```text
[旧方案] 单聊天框 + 直接调模型 + 硬编码工具
    |
    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、架构

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

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

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

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

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

# 05、实战一次

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

核心实现如下：

```python
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螺栓'}))
```

启动方式：

```bash
python agent_runtime.py
```

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

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

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

```json
{"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、演进

```text
[同一输入]
    |
    +--[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、小结

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

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

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

# 12、作业

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

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

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

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

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

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

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

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

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

# 13、思考

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

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

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

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

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

企业级智能体的关键不是多一个聊天框，而是统一治理企业上下文、身份、权限与执行。本文用系统思维与安全边际，拆解Gemini Agent背后的执行链设计。

架构师

架构设计

后端

人工智能

企业智能体落地关键在于统一治理层：身份权限、审计、预算、幂等与状态持久化，模型越强越需决策与执行分离，安全边际决定自动化上限。跨系统长任务需先定验收标准，再以可回滚架构实现生产级可控执行。

聊天机器人

数据脱敏

数据仓库

代码解释

智能体

路由

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

技术思考问题1：通用工作智能体落地企业架构上最大的挑战是什么？-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐