在Agentforce的生态中，Actions是连接Agent与数据、业务逻辑的核心桥梁。今天我们来深入聊聊，如何通过几种不同的技术路径来创建这些Actions，从声明式到程序化，从标准UI到完全自定义的交互体验，看看它们各自适合什么场景。
AuraEnabled 控制器方法创建 Actions
如果你熟悉Lightning Aura组件的开发，那么对@AuraEnabled注解一定不陌生。现在，借助Agentforce Vibes Extension，你可以为带有这个注解的Apex控制器方法自动生成OpenAPI v3规范文档。这个流程和Apex REST Actions几乎一致：先生成OAS，然后验证，接着把类和元数据部署到API目录，最后在Builder中创建Agent Action。简单来说，就是把已有的AuraEnabled方法，快速包装成Agent可调用的接口。
AuraEnabled Apex 类限制
需要注意的是，API目录本身有容量上限。如果达到限制，就得先停用或删除一些不需要的操作——当然，前提是先从Agent Action中移除对这些操作的引用。具体可以参考官方文档中关于API目录视图、AuraEnabled注解以及Lightning Aura组件和LWC开发指南的内容。
Named Query API Actions
如果你不想写Apex代码，又想快速把数据查询暴露给Agent，Named Query API是最直接的方式。你只需要在Setup中定义好自定义的SOQL查询，系统会自动将其转化为Agent Action。本质上，它就是一个可复用的、带名字的查询模板。
所需权限
要操作Named Query API，需要具备创建、读取、更新、删除相应记录的权限。而使用带Named Query的Agent，则至少需要View Developer Name或View Setup and Configuration权限。
设置和使用流程
整个配置过程很清晰：首先在Setup的User Interface中启用“Salesforce Platform REST API, Named Query for Agent Actions”这个开关。然后创建Named Query APIs，也就是编写你的SOQL查询——这些查询会出现在Setup的API Catalog中，需要手动激活才能使用。接下来，在Setup的Agentforce Assets中找到Actions，新建一个Agent Action，选择Reference Action Type为API，Category为Salesforce Named Query API，最后从列表中选择你想要的查询即可。
注意：执行命名查询的用户，必须对所查询的数据具有读取权限，否则会报错。
Apex Invocable Method Actions
再进一步，如果你需要更复杂的业务逻辑，比如调用外部系统、执行多步处理，那么@InvocableMethod注解就是你的最佳选择。它允许你直接从Apex代码创建自定义动作，是Apex集成的最直接方式。
关键注解
两个核心注解需要掌握：@InvocableMethod用来标记方法可被Agent调用，它的label和description属性非常关键，Agent正是根据这些信息来决定何时调用这个方法。@InvocableVariable则用于定义输入和输出参数，同样需要填写清晰的label和description，告诉Agent每个字段的具体含义。
代码结构示例
一个典型的代码结构如下：一个public with sharing的类，内部包含一个静态的、被@InvocableMethod标注的方法，方法接受一个List作为输入，返回一个List作为输出。输入和输出类各自使用@InvocableVariable定义字段。比如一个HelloWorld的例子，接收一个名字，返回一个问候语。
public with sharing class HelloWorld {
@InvocableMethod(label='Hello World' description='Takes a name and returns a greeting')
public static List sayHello(List inputs) {
// 处理输入，返回输出
}
public class InputParameters {
@InvocableVariable(required=true label='Name' description='...')
public String name;
}
public class OutputParameters {
@InvocableVariable(label='Greeting' description='...')
public String greeting;
}
} 重要模式
有几个模式需要牢记：方法必须是静态的，并且无论单次调用还是批量，都接受和返回List。输入和输出类中的每个字段都要用@InvocableVariable标注。label和description的填写质量，直接决定了Agent能否正确理解和使用这个动作，这一点怎么强调都不为过。
使用 Lightning Types 自定义 UI
前面讲的方法，Agent交互时展示的UI都是默认的。但如果你想让Agent的聊天界面更酷、更品牌化、更具交互性，那就需要自定义Lightning Web Components。不过要注意，这种方式只适用于使用Apex类作为输入输出的Agent Actions。
入门路径
上手路径很灵活：你可以在Setup中直接创建，也可以先理解核心概念、文件结构和Schema投影。方法选择上，可以用Apex类驱动，也可以手动编写JSON Schema。构建时，需要结构化LightningTypeBundle元数据。如果觉得手写麻烦，还可以借助Agentforce Vibes中的Lightning Types skill，用自然语言描述，让AI帮你生成。最后通过Metadata API或Salesforce CLI进行部署。
标准 Lightning Types 工作原理
理解标准Lightning Types的机制很重要。它会将Apex的输入输出类型自动映射到标准的Lightning类型，比如date对应lightning__dateType，string对应lightning__stringType。每个标准类型都有对应的Schema验证规则。Salesforce会根据映射类型自动生成UI组件，多行文本就变成文本框，日期就变成日期选择器，列表就变成表格。动作执行时，Renderer组件负责显示结构化数据。总的来说，标准类型提供了开箱即用的组件，大部分场景下只需要很少的配置。
如果你想集成自定义的Lightning Type，也很简单：打开Agent Action，编辑Input Rendering或Output Rendering参数，选择你创建的自定义Lightning类型，保存即可。
航班预订示例：自定义 Lightning Types
光说理论可能不够直观，我们来看一个完整的航班搜索Agent Action示例。这个例子会展示如何通过自定义Lightning Types，彻底改善输入和输出的UI体验。
Apex 类
首先创建两个Apex类：FlightSearchAction（包含@InvocableMethod，处理航班搜索的核心逻辑），以及对应的输入和输出参数类型。输出中包含了航班选项列表、价格、折扣信息等字段。
创建 Agent Action 和默认 UI 问题
当你创建好Agent Action后，默认的UI可能会显得比较杂乱：标签不清晰，没有操作按钮，折扣信息也不突出。这就是自定义Lightning Types发挥价值的地方。你可以创建两个自定义Lightning类型：一个用于输出钱I（flightResponse CLT），让信息展示更清晰、布局更吸引人、折扣信息高亮显示，并且加上醒目的“Book Now”按钮；另一个用于输入UI（flightFilter CLT），让用户交互更直观。
改造前后对比
从默认UI到自定义UI，对比非常明显：前者杂乱无章，后者清晰美观、信息层级分明、操作按钮突出。用户体验的提升是质的飞跃。
从简单的Named Query，到完整的@InvocableMethod集成，再到通过自定义Lightning Type打造极致的UI体验——Agentforce Actions提供了从声明式到程序化、从标准到完全自定义的完整灵活度。你可以根据实际场景和团队能力，选择最适合自己的那条路。