Agent 框架的 75 项功能缺口：身份、可靠性、意图仍需突破

经过过去几个月查阅 n8n、Google、Gumloop 等公司的数百份技术文档，我总结了一份 agent 开发工具应该具备的 75 项能力。

但是还有很多事情是你可以、需要或应该对 agent 进行的，而这些内容难以或不适合纳入报告，所以我在这里分享其中一些。

Agent Identity

Agent 已经明确陷入了人类身份和非人类身份之间的灰色地带，这是有问题的，因为没有办法跟踪 agent、它们的行为及其所有者。如果 Agent X 决定进行大规模数据删除，身份识别是帮助你找出它在哪里以及谁创建了这个 "怪物" 的关键。

但目前还没有人解决身份识别问题，如果他们声称已经解决，也只是通过改造现有技术来适应 agent，这并不真正有效（值得注意的是身份验证（Auth）的情况比身份识别（Identity）好一些，但身份验证只是身份识别的一个子集）。

假设你在 n8n 中运行 agent。目前没有办法正式定义 agent 的身份，使得你可以给它分配一个名称标签、一些策略，并在更广泛的工作环境中监控它的活动。你可以将其与支持 agent 的身份提供者（IdP）集成，但仍然需要自己处理工程细节。

这份资源详细说明了如何将 n8n agent 接入微软的 Entra Agent ID。虽然该资源需要付费查看，但它说明你需要：

一个运行在 Azure Container Apps 上的 n8n 实例，配有 HTTPS 入口、持久化 Postgres 和文件存储。

微软 Entra Agent Identity 蓝图、Agent Identity 服务主体和 Agent 用户账户

执行微软 Graph 调用的 n8n 工作流、一个代理 token 的 Auth Manager，以及与企业 Microsoft Graph MCP Server 通信的代理 webhook。

从 agent 内部成功执行的 MCP.User.Read.All 委托调用。

目前原生运行此方案的最佳选择是使用 Google Gemini Enterprise Agent Platform，这显然是超大规模云厂商的产品组合优势。Agent Identity 为每个 agent 提供了基于 SPIFFE 标准的强证明加密身份。通过 Agent Identity，agent 可以安全地认证到 MCP server、云资源、端点和其他 agent，既可以代表自己行动，也可以代表终端用户行动。Agent Identity 使用 agent 自己的凭证和 Agent Identity auth manager。Auth manager 可以创建和管理 auth provider，这些是用于获取、管理和保护 API key、OAuth 客户端 ID、OAuth 客户端密钥和委托的终端用户 OAuth token 的特定配置。

但即使是 Google 的方案（目前最先进的方案之一）也存在一些批评意见，比如他们对 SPIFFE 的使用。"虽然 SPIFFE 在技术上可以提供 agent 身份，但当前的 Kubernetes 实现将所有副本视为相同的——这与 agent 的非确定性、上下文相关的行为根本不匹配，产生了合规性和归属性差距"。

Agent Reliable Execution

LLM 生成代码，agent 执行代码。就像服务器出问题需要重启一样，agent 也可能出现故障。所有企业都感受过这种痛点，但我看到很少有系统性的（或者说确定性的）方法来确保 agent 能够可靠执行。有一些工具正在处理这个问题，但采用速度很慢。

最简单的能执行 agent 代码的东西是 Python 解释器。你应该期望一个 agent 开发工具能做的远不止直接运行 Python，包括：

防止困惑代理（Confused Deputy）：沙箱（如 MicroVM/Wasm）能够安全地运行不受信任的 AI 代码，或提供受限的网络访问

持久性：检测失败、重试步骤、维护状态、检查点、验证结果

并发：资源分配和处理服务扩展时的噪声邻居（noisy neighbor）问题

我们在报告中简要涉及了代码执行和沙箱，现在让我们看看其他两个方面：

Agent 执行持久性

Agent 可能会遇到 LLM 提供商的速率限制、请求超时，或自托管的 agent 可能内存不足。

执行持久性可以通过以下方式帮助从这类事件中恢复：

检查 agent 任务是否得到执行，已完成的步骤是否被存储

如果 agent 被中断，它会从同一位置重新开始

它们被执行一次，而不是零次或多次

Agent 行为具有时间感知，使得它们等待其他任务完成、遵循计划等

如果输出未通过验证，可以回退并重试

并发

Agent 和底层托管环境争夺内存、CPU 和网络调用。当 agent 共享同一基础设施（即没有隔离）时，一个资源密集型会话会降低所有其他会话的性能。有效的并发管理需要内核级配额强制执行、跨异构工作负载的实时调度，以及能够阻止 agent 调用突发级联到下游故障的反压机制。

为了在基础设施层支持并发，你可以通过 cgroup 在内核级强制每个会话的资源限制、维持实时集群状态用于调度决策，并通过 microVM 或 gVisor 边界隔离会话，以防止 agent 之间的噪声邻居溢出。

在执行层，你可以在工作流执行和 worker 容量上强制并发限制，防止对受限速率的 LLM 或外部 API 运行过多 agent 任务。这是工作流级别的反压，而不是计算级别的资源隔离。

其他并发控制包括任务队列，比如限制一个步骤或函数有多少个实例并行运行。这对防止 LLM 速率限制耗尽很有用，但无法解决会话之间的底层资源争用。

Intent

LLM 的偏离是设计使然，仅仅说 "请不要偏离" 或启动一个 orchestrator agent 并要求它 "请不要偏离" 是没有帮助的。

你必然会遇到 agent 没有完成分配的任务、做了别的事情、报告了一个不完整任务的完成，或者只是产生了幻觉结果的情况。你需要监控行为偏离，以确定 agent 的逻辑是否对其范围和请求仍然充分。这需要持续扫描对话和代码级执行，查看它想调用哪些库、被调用的函数会实际达成什么、LLM 在对操作系统做什么。它追踪响应中的推理字段和工具调用字段，以理解每一次逻辑委托和为什么这样做。

虽然在安全方面有大量工作来防止 prompt 注入和困惑代理问题，但在防止非恶意偏离方面的工作很少。

你可以在基于 LLM 和非基于 LLM 的意图分析之间选择。

基于 LLM 的易于实现且通用。缺点是 LLM 判断器继承了它们试图解决的相同问题。不管怎样，其中一些包括：

衡量 agentic 轨迹正确性和连贯性的评估指标

衡量用户在会话期间相对于其最初陈述的意图，主要对话目标或工作流的转变

评估每个行动向目标推进的有效性

非基于 LLM 的意图分析更难实现，需要提前思考，这在 "氛围编码" 社会中是一个挑战。它包括：

使用只有编码器的模型，如 BERT 或 ModernBERT，它们理解文本但不生成文本，并用它们输出二进制是/否。

追踪（即数据库写入）agent 是否成功完成了用户的所有目标。

定义不可变的作用域，通过一组步骤强制 agent 执行，这些步骤可以在推理过程中或由 orchestrator agent 定义。

定义特定于任务的边界、进行任务的权限、可用的工具、是否可以生成子 agent。

Agent 开发工具能做什么

在报告的第二次迭代中，我们根据 75 项能力评估了工具，范围从代码执行和沙箱到身份验证和紧急停止开关。一些功能已高度商品化，而其他功能则是明显的差异化因素。

在此处阅读完整报告

n8n 用户来自广泛的背景、经验水平和兴趣。我们一直在寻求在博客文章中突出不同用户及其项目。如果你正在使用 n8n 并想激励社区，请联系我们 💌