SAP 官方实战拆解:用 Joule Studio 把自建 AI Core Agent 接成对话式 Skill
素材来源SAP Community 官方技术博客《Custom Agentic Chatbot with SAP AI Core and Joule Studio — Part 3 (2): Creating a Joule Skill (Design Release)》原文链接https://community.sap.com/t5/technology-blog-posts-by-sap/custom-agentic-chatbot-with-sap-ai-core-and-joule-studio-part-3-2/ba-p/14235502本文是基于原文的中文拆解 落地补充技术细节以原文为准。这是 SAP 官方「Custom Agentic Chatbot with SAP AI Core and Joule Studio」系列的第 5 篇Part 3 的第 2 小篇也是整套链路里最贴近可用的一节前面几篇你已经把 Agent 后端写出来、塞进容器、部署到 SAP AI Core并且通过 BTP Destination 打通了 Joule Studio 到 AI Core 的连接这一篇要做的事只有一件——让它能聊天。先给一个完整地图方便定位篇章内容Part 1Building the Custom AI Agent Backend写后端Part 2 (1)Deploying the Agent on AI Core — Environment Containerization环境与容器化Part 2 (2)Deploying the Agent on AI Core — Deployment Testing部署与测试Part 3 (1)Setting Up Joule Studio Connection — Destination Environment打通连接Part 3 (2)Creating a Joule Skill — Design Release本文Part 3 (3)Testing and Sharing on Work Zone测试与发布到 Work Zone一、Skill 在 Joule 体系里到底是什么原文给了一句非常关键的定义A Skill defines how Joule interprets user messages and which Actions to trigger in response.翻成大白话Skill 是意图 → 后端调用的映射规则 编排流程。它自己不生产智能智能在你的 AI Core 后端里Skill 负责三件事判断用户这句话该不该我管意图识别从用户输入里抠出参数槽位填充按什么顺序去调后端的哪些接口编排。理解这一点很重要因为很多人的第一反应是AI 应该自己决定调什么于是把 Skill 写得极其宽泛结果触发极不稳定。原文专门给了一条 TipUse an explicit activation phrase (like/CustomAgent) to ensure the skill consistently triggers only when intended.这是老手才会写的建议。Joule 的意图路由是基于 Skill 的 Description 做语义匹配的描述写得越模糊触发就越随机。加一个显式激活短语等于给意图识别加了一道确定性的兜底。测试阶段强烈建议这么做——先把链路调通再考虑放宽触发条件。二、创建 SkillLobby → General → Parameters1. 入口SAP Build Lobby → Create → Joule Skill原文把 Skill 命名为CustomAgent并注明this will act as the main entry point of your agent。另外一句容易被忽略的话In Joule Studio, skills can be nested.也就是说 Skill 是可以嵌套的你可以把它建在某个已有上下文里形成主 Skill → 子 Skill 的层级结构。这在复杂 Agent 场景比如一个运维助手下面挂查日志“建工单”跑批处理三个子技能里是刚需。2. General 页签两个开关是重点配置项原文取值含义NameCustomAgentSkill 名称DescriptionA skill to activate custom agent. Activate this skill if users request contains /CustomAgent.决定何时触发最重要Allow Joule to generate a responseOff不让 Joule 自己再生成回复Allow skill to be started directly by a userOn允许用户在对话里直接触发为什么 “Allow Joule to generate a response” 要关掉原文解释是用 “Send Message” 步骤代替。背后的原因值得展开你的后端跑在 AI Core 里的容器已经返回了完整、可控的业务内容如果再让 Joule 的 LLM 基于这段内容润色一遍就等于引入了一次不可控的二次生成——格式可能被改坏、数字可能被改写、延迟和 token 成本翻倍对 SAP 这种强合规场景可预期 更自然。我的建议除非你的后端只返回结构化数据比如一串 JSON需要 LLM 转写成自然语言否则一律关掉。3. Parameters 页签会话状态怎么传原文定义了两个参数参数名用途message用户本轮实际输入conversation_id追踪连续对话会话不传则后端新建关键机制是这句When parameters are defined at the skill level, Joule automatically parses values from the user’s chat input and makes them available as variables in subsequent nodes.也就是说Joule 会自动从用户输入里抽取参数值你在后续节点里直接用{{message}}、{{conversation_id}}引用即可。这里藏着整套方案最容易踩的坑conversation_id。跑在 AI Core 上的容器本质上是无状态的 HTTP 服务而且可能多实例、会被调度重启。如果你想让 Agent 记住上一轮说了什么就必须在每一跳显式把conversation_id传回去让后端自己去对象存储或 Redis 里捞上下文。原文那句 “if not provided, the backend will start a new one” 说得很清楚——不传就是新会话用户会觉得你的 Agent 得了健忘症。三、把多个 Action 串成一条链原文给出的完整调用链是/v2/plan → /v2/action-graph → /v2/start-execution → /v2/continue-execution这是一个典型的Agent 执行循环被拆成了四次 HTTP 调用端点作用按命名推断的职责/v2/plan根据用户意图生成执行计划/v2/action-graph把计划展开成可执行的动作图/v2/start-execution启动执行/v2/continue-execution继续执行 / 推进后续步骤注意到最后两个端点的命名了吗——start 和 continue 分开说明后端执行是异步、可中断、可续跑的。这对 Joule Skill 的设计有直接影响你不能假设调一次就拿到最终结果而要在中间插入 Message 节点给用户反馈进度。原文的说法是Each Action node represents a backend call, while the Message nodes in between provide real-time feedback so users can monitor progress.这是这套编排里最实用的设计。长任务跑一批 ABAP 测试用例、迁移一批物料主数据动辄几十秒甚至几分钟没有中间反馈用户会以为系统死了。四、变量与表达式怎么把上一步的结果喂给下一步原文给了两类写法务必分清1. 双花括号{{...}}—— Skill 参数 / 用户输入{{message}} → 传给 /v2/plan 或 /v2/action-graph {{conversation_id}} → 维持 AI Core 侧会话上下文 {{plan.content}} → 引用上一个 Action 的输出字段2.${context...}—— Action 返回结果Message 节点里用原文示例Message Configuration${context.joule_action_...result.conversation_id} → 取 Action 返回的 conversation_id ${context.joule_action_...result.content} → 展示生成的 plan 内容 ${context.joule_action_...result.timestamp} → 展示响应时间原文把这种机制形容得非常贴切This lets your Joule Skill behave like a data pipeline, passing both user inputs and Action results through the workflow.Skill 就是一条数据管道。用这个心智模型去设计你会发现很多编排问题参数从哪来、结果到哪去、中间要不要转换都能迎刃而解。至于${context.joule_action_...result.xxx}里那个...是具体 Action 的节点标识实际使用时以 Joule Studio 编辑器里自动补全出来的路径为准——不要手敲去编辑器里选。五、落地时我建议额外考虑的四件事原文止步于设计完成下一步去 Part 3 (3) 测试并发布到 Work Zone。但真要上生产还有几条原文没写、你迟早会遇到的超时与兜底Joule Skill 的一个 Action 节点等待后端是有上限的。你的/v2/start-execution如果可能跑 5 分钟必须设计成提交任务返回 job id 后续轮询 / 异步通知别让 Skill 干等。conversation_id的生命周期后端要定过期策略比如 24 小时或 30 轮无活动清理否则对象存储里会堆积大量僵尸会话上下文成本和检索延迟都会上升。幂等性/v2/continue-execution这种推进型接口网络抖动导致重发是大概率事件。后端必须对同一个conversation_id 同一个 step 做幂等否则会出现动作重复执行。别一上来就追求自然语言触发先用/CustomAgent这种显式短语把链路跑通、把回归测试用例固化下来再逐步放宽 Description 的语义范围。意图路由的调优是个长期活儿跟链路调通混在一起做会非常痛苦。六、一句话总结这一篇的实质是把你已经在 AI Core 里跑起来的自定义 Agent通过 Joule Skill 的意图识别 参数抽取 多 Action 编排包装成企业用户能直接对话的形态。三个必须记住的点Description 决定触发用显式激活短语保底conversation_id是无状态容器下维持记忆的生命线每一跳都要传Action 之间插 Message 节点长任务必须给进度反馈。下一篇Part 3 (3)会讲如何在 Joule Chat 里实测、以及发布到 Work Zone 给全组织使用。参考链接原文https://community.sap.com/t5/technology-blog-posts-by-sap/custom-agentic-chatbot-with-sap-ai-core-and-joule-studio-part-3-2/ba-p/14235502SAP Build Lobbyhttps://community.sap.com/SAP AI Core 文档https://help.sap.com/docs/sap-ai-core