使用ADK构建企业级智能体：2026年生产就绪的真实面貌

2026年Agent栈的现状

十二个月前，“构建一个Agent”意味着把一个大语言模型、几个工具和你自己写的提示循环拼在一起。2025年4月，Google在Cloud NEXT大会上开源了Agent开发工具包(ADK)。到2026年Cloud NEXT大会时，它已成为生产级Agent在Python、TypeScript、Go和Java中的默认代码优先框架，Vertex AI Agent Engine作为托管运行时，模型上下文协议(MCP)则作为得到Anthropic、OpenAI、Google和Microsoft支持的集成标准脱颖而出。

与此同时，Anthropic发布了Claude Code，OpenAI发布了Codex，PolyAI推出了自己的客户体验ADK，大多数主要模型提供商也都发布了某种形式的Agent运行时。基础设施的问题已不再是“我们能构建Agent吗？”，而是“我们能在企业规模上安全运行它们吗？”

关于后一个问题的数据相当严峻。Gravitee的《2026年AI Agent安全状况报告》调查了900名高管和从业者。81%的团队已经过了规划阶段。只有14.4%获得了完整的安全批准。88%的受访者表示在过去一年中发生过确认或疑似Agent安全事故。Gartner预测，到2027年底，40%的Agent AI项目将因成本上升、业务价值不明或风险控制不足而失败或取消。

Writer的2026年企业调查发现，67%的高管认为他们的公司已经因未经批准的AI工具而遭受数据泄露，36%没有正式的Agent监督计划，35%承认他们无法立即“拔掉”一个作恶Agent的电源。

这篇文章旨在讲述如何真正在ADK上交付Agent而避免成为那些统计数字中的一员，特别是如果你是一个Web3企业，其中Agent行为不当的爆炸半径不是泄露的备忘录，而是被掏空的钱包。

ADK实际给了你什么

ADK是一个为生产环境优化的代码优先框架。核心原语：

• Agent和工具。 将Agent定义为一个Python（或TS/Go/Java）类，带有指令、模型和Agent可以调用的一组工具。
• 多Agent编排。 将Agent组合成层次结构。协调器将工作路由给专家。顺序、并行和循环工作流Agent处理确定性流水线；LLM驱动的动态路由处理自适应路径。
• 工具生态系统。 预置的100+企业系统连接器，以及支持自定义工具、OpenAPI规范和MCP暴露的工具。
• 内置评估。 针对预定义案例测试最终响应 和 逐步轨迹。对于生产中的回归测试至关重要。
• 工具确认。 在工具执行上设置人机协同门控，带有明确的确认流程。
• 随处部署。 容器化并在你自己的基础设施、Cloud Run、GKE或Agent Engine上运行。

一个最小的ADK Agent看起来像这样：

记住我以便更快登录

python

from google.adk.agents import Agent
from google.adk.models import Gemini
root_agent = Agent(
    name="treasury_agent",
    model=Gemini(model="gemini-flash-latest"),
    instruction="""你是一个资金运营助手。
    你可以读取余额和提出交易，但不能签名或广播。
    所有交易都会交给人类审批人。""",
    tools=[read_balance, propose_transaction],
)

这就是框架按预期工作的样子。框架本身并不难。难点在于所有决定Agent能否安全部署的其他因素。

ADK没有给你什么（以及你必须构建什么）

ADK在Agent循环方面非常出色。但它默认没有解决使生产部署变得有风险的操作和安全问题。这些是你的问题，并且集中在五个方面。

1. Agent身份和凭证管理

只有22%的团队将Agent视为独立身份。其余团队依赖共享的API密钥，这意味着当出现问题时，无法进行归属，撤销也是破坏性的。你的每个Agent都应该拥有：

• 自己的服务账号或限定范围的凭证
• 记录在案的权限边界（默认只读，只有针对明确、经过审计的工具才可写）
• 自动轮换和按环境隔离
• 每次工具调用时记录的身份上下文

2. 连接处的工具授权

ADK的工具确认功能是一个起点，而不是完整的答案。真正的问题是策略：哪些工具需要批准，在什么条件下，超时时间是多少，以及谁有权批准。对于Web3企业，答案是结构性的。只读工具（余额查询、索引器读取）可以自动批准。改变状态的工具（交易签名、合约调用）需要通过具有链上时间锁语义的多方批准流程进行门控。

3. 超越Cloud Trace的可观测性

Cloud Trace提供跨度级别的延迟。它不会告诉你Agent决定做什么、为什么以及它差点做了什么。生产部署需要：

• 完整的提示和响应日志，并在写入时进行PII脱敏
• 每次工具调用的结构化事件模式，包括被拒绝的调用
• 用于事件分析的回放能力
• 每个Agent和每个工作流的成本跟踪

4. 故障模式覆盖

LLM会幻觉出工具。Agent会循环。工具会超时。网络会失败。框架处理了其中一部分；你的应用代码必须处理其余部分。具体来说：

• 带断路器的有界重试策略
• 检测和拒绝幻觉产生的工具名称或参数
• 当关键工具不可用时的优雅降级路径
• 一个记录在案的杀死开关，能够在60秒内将Agent脱离服务

5. 能够应对生产漂移的评估

ADK内置的评估框架是真实且有用的，但这还不够。随着模型更新、提示演变和工具变化，生产Agent会发生漂移。成熟的团队在保留的一组黄金轨迹上运行持续评估，对回归发出警报，并根据评估通过率来控制部署。

Web3角度：触及链上系统的Agent

以上几点适用于任何企业。它们对Web3企业而言更为重要，因为故障模式在种类上（而不仅仅是程度上）有所不同。

在SaaS公司，行为不当的Agent会写一封糟糕的电子邮件。在代币化平台、DeFi协议或资金管理公司，行为不当的Agent会签署一笔不可逆转的交易。同样的治理漏洞，在其他地方会导致备忘录泄露，在链上则会导致资产的永久损失。

这是需要最严格审查的边界：

• 暴露链上工具的MCP服务器 必须具有Agent无法通过提示注入绕过的授权逻辑。权威存在于服务器中，而非提示中。
• 交易签名工具 永远不应自动可调用。每个签名工具都通过人工审批或单独认证的联合签名者进行门控。
• 读写不对称性 必须明确。读取价格源可以自动批准。通过“可信”管理路径向预言机写入则不行。
• 企业风险模型中内置的赔偿和可逆性假设 不能直接迁移到链上操作。威胁建模必须考虑到“我们将回滚数据库”这一选项不再可行。

你的团队现在正在交付的Agent正在与智能合约交互，这些合约是其他团队在部署时审计过的。审计并未涵盖Agent。Agent是系统中的一个新参与者，需要作为新参与者进行威胁建模。

Ancilar如何参与

我们与在ADK及类似框架上部署Agent的Web3企业和Web3相关平台合作。我们最常进行的合作包括：

• Agent-工具边界审查。 我们映射Agent可以调用的每个工具，按爆炸半径进行分类，并验证授权逻辑是在服务器端强制执行的，而不是依赖于Agent的提示。
• MCP服务器加固。 我们审计的大多数生产MCP服务器都存在授权漏洞、提示注入漏洞或缺失速率限制。我们在它们进入生产流量之前关闭这些漏洞。
• Agent驱动的链上操作威胁建模。 当一个LLM处于你的资金调用路径中时，这会对你的安全模型意味着什么？我们以书面形式回答这个问题，并给出具体建议。
• 自定义工具预审计审查。 Agent的安全取决于它们调用的工具。我们审查工具实现本身，特别是那些触及合约状态、预言机数据或签名基础设施的工具。

对于现在正在规划Agent项目的创始人和平台负责人，这项工作也可以作为治理文档。董事会和资金提供方越来越频繁地询问当LLM参与循环时存在哪些控制措施，而书面的Agent威胁模型可以用具体细节回答这个问题。

如果你正在ADK上构建，并且“我们如何安全地交付这个”的问题开始超过“我们如何快速交付这个”的问题，那么这正是我们准备好进行对话的领域。

安排一次与Ancilar的Agent安全审查： www.ancilar.com/services

• 原文链接： medium.com/@ancilartech/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～