Agentforce 操作指南 (2026)：本地流程 vs. MuleSoft vs. 外部服务
Source: Dev.to
请提供您希望翻译的完整文本内容，我将按照要求将其翻译为简体中文并保留原始的格式、Markdown 语法以及技术术语。
概览
Salesforce 的 Agentforce 运行在 Atlas 推理引擎上，以 reason → act → observe 循环执行真实的业务工作——不仅仅是回答问题。如果你的代理完全在 Salesforce 内部运行（更新 Opportunity、查询 Data Cloud），可以快速交付。
大多数部署在代理需要 与其余技术栈交互 时会卡住——向 Slack 发送消息、更新 Jira/Linear、检查 GitHub PR、安排会议，或创建 PagerDuty 事件。这时 “Actions” 成为瓶颈。
Salesforce 文档会引导你使用 Flow HTTP Callouts、Standard Actions 库 或 MuleSoft。对于希望快速推进且不想破坏预算或安全姿态的工程团队来说，每种方案都存在显著的取舍。
什么是 Agentforce “Action”？
An Agentforce Action 是一种可调用的工具，Atlas 引擎可以调用它来执行计划中的一步。操作可以在以下两种情况下运行：
- Within Salesforce – 本地操作（例如，更新记录）。
- In external systems – 通过从 OpenAPI 规范生成的 External Services 操作。
只有当代理能够在整个 SaaS 生态系统中可靠且安全地执行操作，并拥有适当的权限时，推理才有意义。
关键要点
| 问题 | 洞察 |
|---|---|
| 瓶颈 | Agentforce 能进行推理，但当代理无法可靠执行 外部操作 时，部署会失败。 |
| 原生权衡 | Flow HTTP 调用 + 每用户命名凭据会增加持续的身份验证/管理负担；模式更改可能导致流程中断。 |
| 覆盖空白 | 标准操作和连接器很少覆盖长尾或深层端点。 |
| 最佳模式 | 将策划的 OpenAPI 规范导入 External Services，创建可发现的 Agentforce 操作，无需脆弱的粘合代码。 |
| 解决方案 | Composio 充当桥梁，生成安全、符合 OpenAPI 的连接器，可直接导入 Salesforce 作为 Actions。 |
| 结果 | 在几天内部署深度集成的代理，访问 SaaS 工具的“长尾”，并严格执行用户级安全。 |
Agentforce 操作瓶颈（为何大多数部署停滞）
Atlas engine 使用了一个复杂的推理循环：
- Reason – 评估用户查询。
- Plan – 制定回答路径。
- Act – 寻找可执行该计划的工具（Actions）。
如果代理完全运行在 CRM 内部（更新 Opportunities 或查询 Data Cloud），则没有问题。
当业务逻辑延伸到 Salesforce 之外时，就会出现摩擦。若 Sales Agent 无法安排 Google Calendar 会议则毫无用处；若 Support Agent 不能检查 Linear 工单状态则会失效。
弥合 “Actions Gap” 的三种常见选择
| 方法 | 描述 |
|---|---|
| Flow HTTP Callouts / Apex | 启动快，但在规模化时很快变得脆弱且难以管理。 |
| Standard Actions / MuleSoft | 提供广度或深度，但常常牺牲速度或需要繁重的治理。 |
| Generic iPaaS | 提供系统级连接性，但缺乏每用户的安全上下文。 |
这些模式往往难以满足 Agentforce 的特定需求。
Agentforce 集成选项对比
| 选项 | 上线时间 | 长尾覆盖范围 | 接口深度 | 每用户安全性 | 运维负担 | 常见故障模式 |
|---|---|---|---|---|---|---|
| Flow HTTP Callouts + Apex | 中等 | 高（自行实现） | 高（自行实现） | 可能（困难） | 高 | 架构映射错误；认证散乱 |
| Standard Actions library | 快速 | 低‑中 | 低‑中 | 取决于 | 低 | 缺少端点或工作流细节 |
| MuleSoft | 较慢‑中等 | 中等 | 中等‑高 | 强（若设计） | 中等‑高 | 对长尾而言过度；迭代缓慢 |
| Generic iPaaS (system key) | 快速 | 高 | 中等 | 弱 | 中等 | “系统用户” 数据泄漏风险 |
| Curated OpenAPI → External Services (Composio) | 快速 | 高 | 高 | 强 | 低‑中 | 动作范围错误或治理缺口 |
为什么标准集成模式会让 Agentforce 失效
1. Flow HTTP Callouts 与 Apex（管理陷阱）
Salesforce 在这方面已有改进：你可以使用 Named Credentials 进行 OAuth 握手，使用 Flow HTTP Callouts 实现无代码集成。这对简单的系统对系统连接效果很好。
摩擦点
| 问题 | 为什么重要 |
|---|---|
| 用户上下文 | Agentforce 必须 以用户身份 行动（例如，“以 Sarah 的身份在 Slack 中发帖”）。要原生实现此需求，需要为每个用户创建 Named Credential，这意味着必须为每个外部工具设置单独的 Auth Provider 并管理细粒度的权限范围。规模化非常痛苦。 |
| 模式复杂性 | 现代 API（Jira、GitHub）返回庞大且嵌套的 JSON。Flow HTTP Callouts 往往在这些模式上卡顿。 |
| 维护成本 | 仍需手动映射输入/输出。如果外部 API 变更，Flow 会中断，代理也会失效。 |
2. 标准操作与 MuleSoft（广度 vs. 深度 vs. 速度）
Salesforce 正在快速构建针对主要平台（Jira、ServiceNow 等）的 “Standard Actions” 库。如果标准操作正好满足你的需求，就直接使用它。
现实情况
- 广度缺口（长尾） – 大多数组织使用 50 + 种工具（Linear、Notion、PagerDuty、Brex、Asana 等）。Salesforce 不会为所有工具都构建原生连接器。为这些长尾应用启动 MuleSoft 项目会严重拖慢交付速度。
- 深度缺口 – 标准连接器只暴露大约前 10 % 的 API 端点（例如 “Create Ticket”）。如果你的代理需要 “更新自定义字段” 或 “获取转换历史”，而该端点未被暴露，你又回到原点：自己动手构建。
3. 通用 iPaaS（系统密钥集成）
许多团队转向通用 iPaaS，并使用 单一系统用户 进行连接。这可以快速实现高广度的连通性，但：
| 关注点 | 影响 |
|---|---|
| 安全上下文 | 操作在系统账户下运行，失去每个用户的来源追踪。 |
| 数据泄漏风险 | 用户可能无意中对他们不该访问的数据执行操作。 |
Composio 解决方案
Composio 生成安全、符合 OpenAPI 标准的连接器，可直接导入到 Salesforce 作为 External Services 动作。
- 精选的 OpenAPI 规范 → 作为可发现的动作导入。
- 基于用户的安全 自动通过 Named Credentials 强制执行。
- 低运维负担 – 无需自定义 Apex，无脆弱的 Flow 映射。
结果
- 在 数天 内部署深度集成的代理。
- 通过 严格执行的用户级安全 访问 SaaS 工具的“长尾”。
- 降低维护开销，加速迭代。
TL;DR
| 需求 | 最佳方案 |
|---|---|
| 快速、按用户的安全外部操作 | 精选 OpenAPI → 外部服务（Composio） |
| 简单的系统对系统调用，低频率 | Flow HTTP 调用 + 命名凭证 |
| 企业级集成，治理严格 | MuleSoft |
| 快速、广泛连接，无需按用户上下文 | 通用 iPaaS（系统密钥） |
通过从脆弱、管理员负担重的模式转向 基于 Composio 的外部服务，您可以消除阻碍大多数 Agentforce 部署的主要瓶颈，释放快速、安全、长尾 SaaS 集成的能力。
安全漏洞（上下文问题）
这是通用 iPaaS 工具（例如 Zapier）最关键的失效点。这些工具通常依赖一个 “系统用户”——一个管理所有访问的 API 密钥。
风险
想象一下，一个实习生向代理询问：“第三季度的战略风险是什么？”
代理在推理需要检查文档时，使用了 Google Drive 的系统密钥来搜索 “Risks”。由于系统密钥拥有管理员权限，代理提取了一份实习生绝不该看到的机密并购文件。
要求
你需要严格的 用户级 OAuth。代理必须 以用户身份 行事，遵守每个用户在外部工具中的具体权限。
Composio 方法：为 Agentforce 管理的操作
Composio 通过提供专门的 AI 代理集成层来解决“免人工”问题。它并不取代您的 MuleSoft 骨干；它处理代理当前所需的灵活、长尾 SaaS 连接，实现 100 % API 覆盖。
- 将 Salesforce 用户映射到外部身份。
- 生成 Salesforce 原生支持的标准 OpenAPI 规范。
工作流
- Connect & Curate – 开发者选择工具（例如 GitHub，Slack）并决定要公开的操作。
- Export – Composio 生成针对 Salesforce 限制进行优化的 精选、严格类型化的 OpenAPI 规范，避免出现“规范膨胀”错误。
- Import – 开发者将优化后的规范导入 Salesforce External Services。
- Deploy – Agentforce 立即将这些新端点识别为可供 Atlas Engine 使用的 Actions。
不再需要与 Flow JSON 解析器搏斗或配置 Auth Providers——只需导入功能即可。
深入了解：“交易室”工作流
场景： 一位销售代表对代理说：
“更新 Acme 交易阶段并通知 solutions 团队频道。”
| 步骤 | 描述 |
|---|---|
| 1. 推理（大脑） | Atlas 识别出两个任务：更新 Salesforce 对象并发送 Slack 消息。 |
| 2. 数据访问（内部） | 代理使用标准的 Salesforce 权限来更新 Opportunity 记录。 |
| 3. 外部操作（双手） | 代理调用在 External Services 中定义的 Composio_Slack_PostMessage 动作。 |
| 4. 身份验证（通道） | 请求通过 Composio 路由，后者将发起用户的 OAuth 凭证注入到请求头中。 |
| 5. 零数据保留 | 有效负载通过加密隧道 不被存储 在 Composio 的数据库中（SOC 2，零知识）。 |
| 6. 观察 | Composio 返回成功标志或结构化错误；Atlas 向用户确认操作结果。 |
关于数据处理的说明： 企业可以配置日志记录/保留策略。Composio 支持 SOC 2 控制，并可根据策略最小化或避免对有效负载的日志记录。
为什么“用户级”认证不可协商
在自主代理的世界里，最小权限是防止数据泄露的唯一防线。当你使用“系统”凭证（在通用集成中常见）时，就会绕过外部 SaaS 工具的安全控制。
Composio 在 Salesforce 用户与外部工具身份之间创建了 1:1 映射，确保代理永远不会默认使用“超级用户”。你可以放心地部署与敏感系统（如 Jira、GitHub 或 HRIS 平台）交互的代理，因为它们的权限永远不会超出指挥它们的人的权限。
Agentforce 操作部署检查清单（生产就绪）
| ✅ | 项目 | 详情 |
|---|---|---|
| 1 | 选择身份模型 | 默认使用 每用户身份验证 以实现最小特权访问。 |
| 2 | 定义操作白名单 | 仅公开代理所需的操作（最小能力原则）。 |
| 3 | 使用精选的 OpenAPI 规范 | 优先使用类型化、简洁、易于导入的规范。避免庞大、原始的 API 定义。 |
| 4 | 验证模式和限制 | 确保请求/响应结构不会破坏运行时（例如，大型嵌套对象、可选字段、分页）。 |
| 5 | 添加策略控制 | 包括日志/保留、审计追踪、环境隔离以及符合安全要求的机密处理。 |
| 6 | 安全失败 | 返回结构化错误信息，以便 Atlas 能够恢复（例如，提示缺少字段、重试或升级）。 |
| 7 | 衡量成本与可靠性 | 跟踪操作成功率、重试次数和超时。由于操作计量，可靠性直接影响投资回报率。 |
使用方法
- 在将操作提升到生产环境之前，审查每一项。
- 确认符合要求后勾选复选框。
- 在对操作定义或部署环境进行任何更改后，重新运行检查清单。
结论
Agentforce 代表了 CRM 的未来，但连接性限制了其潜力。Atlas 推理引擎已经准备就绪，却仍然需要合适的工具才能有效执行。
- 不要让代理因 Flow 中的模式错误而失败。
- 避免为 MuleSoft 连接器等待数周。
- 防止在标准操作缺少所需的特定 API 端点时陷入死胡同。
在 Salesforce 中构建“大脑”。让 Composio 负责“手”。
常见问题
Composio 会存储我的数据吗？
否。 Composio 作为直通执行层运行。身份验证令牌在静止时会被加密，但我们不存储您的代理执行的操作负载（输入或输出）。日志可以配置为零知识，确保符合严格的数据驻留和隐私要求（SOC 2）。
为什么需要 Composio？
- 为每个外部调用提供 用户级 OAuth。
- 生成 精选的 OpenAPI 规范，可顺利导入 Salesforce External Services。
- 充当 安全的、零知识的直通层，消除对自定义中间件或“系统”凭证的需求。
- 提供 细粒度的策略控制（日志记录、保留、审计追踪），满足企业安全标准。
Salesforce 是否有 标准操作？
标准操作在主要平台的日常用例中表现良好（例如 “创建 Jira 工单”）。但在以下情况下会显得不足：
- 访问 “长尾” 应用（Notion、Linear、PagerDuty 等）。
- 执行 深度 操作，例如调用 Jira 中特定的非标准 API 端点。
Composio 通过提供 数百个应用 的连接器并公开 完整的 API 表面（而不仅是最常用的操作）来解决这些限制。
Composio 如何连接到 Salesforce Agentforce？
- 导出 Composio 的标准 OpenAPI 规范。
- 导入 这些规范到 Salesforce External Services。
- Salesforce 生成本机 操作，Agentforce Atlas 引擎即可立即发现并使用。
这会消耗 Salesforce Flex Credits 吗？
是的。操作执行会像其他操作一样消耗 Flex Credits。由于 Composio 连接器是 受维护的 且 严格类型化，可避免因调用失败或自建集成中常见的“幻觉”参数而浪费积分。
Current pricing: $