service-helpagent-coordinate

service-helpagent-coordinate：Service Cloud Help Agent，引导式设置

使用此技能从 Claude Code 在 Salesforce 组织中部署 Service Cloud Help Agent（一种 Agentforce Service Agent），遵循与 Help Agent Quick Setup 向导相同的引导流程。这是一个协调技能：它基于规范协调现有技能，而不会创建新的 Agent 基元。

此技能存在的原因

Salesforce 官方的 Help Agent 模板创建 API 尚未发布。在此之前，Claude 没有内置的「Help Agent」概念，否则会生成通用 Agent。assets/help-agent-spec.md 用于替代缺失的 API：其中的 Agent 脚本是 Quick Start UI 最终生成的规范模板。请将此规范视为 Agent 沿袭关系（主题、操作、指令）的唯一事实来源。

范围

范围内：

• 分为四个检查点的引导式 Help Agent 设置（身份 → 接地 → 渠道 → 上线）
• 通过 Agentforce Data Library（ADL）进行知识接地
• 设置 Web Chat / Help Portal 渠道并在 Experience Cloud 站点中嵌入
• 就绪状态检查（许可证、Einstein Agent User、Data Cloud 权限集）

范围外 — 委托给其他技能：

• OAuth / External Client App 设置 → integration-connectivity-connected-app-configure
• 不含 Help Agent 沿袭关系的原始 Agent 创建 → agentforce-generate
• 元数据部署/检索 → platform-metadata-deploy

先决条件

• 已安装 Claude Code 和 Salesforce CLI，并已通过身份验证的组织（参阅仓库 README.md）
• 已注册 MCP 服务：salesforce-api-context、metadata-experts、sobject-reads
• 已将 Salesforce Skills 安装到 .agents/skills/（或 .claude/skills/）
• 已启用所需功能（或可通过元数据启用）的 Salesforce 组织： Agentforce、Einstein Generative AI、Knowledge、Experience Cloud 和 Data Cloud。任何满足此要求的组织类型均可使用——生产组织、沙盒、临时组织或 Developer Edition。assets/help-agent-spec.md §4.0 中的就绪状态检查会检测每项功能，并启用可启用的功能；如果缺少必需的功能且无法启用，检查会停止并显示清晰的消息。

此技能协调的其他技能

规范会供以下现有技能使用——请勿创建新的 Help Agent 技能：

Skill	作用
agentforce-generate	Agent 创建 + ADL 配置/接地（参阅其 references/data-library-reference.md、references/org-setup-for-adl.md）
dx-org-permission-set-assign	Data Cloud 权限集分配
service-digital-engagement-channel-configure + service-agentforce-channel-configure	部署渠道（Queue 路由），然后 PATCH SessionHandlerId 以绑定 Agent（参阅 references/channel-web-chat.md）
service-digital-engagement-deployment-configure	Embedded Service Deployment — 同时支持 LWR（ChatterNetworkPicasso）和 Aura（ChatterNetwork）站点
experience-lwr-site-generate	Experience Cloud（LWR）站点 — 当组织尚无 Live LWR 站点时使用
service-digital-engagement-messaging-site-integrate	放置小组件 + 嵌入（检查点 4）

技能清单预检（仅供参考——绝不作为硬性阻断条件）

此技能会委托给多个同级技能。根据运行时的不同，这些依赖项可能以两种方式解析：作为 .claude/skills/ 下的目录，或通过运行时技能目录，由执行框架按需解析（没有本地目录）。因此，缺少 .claude/skills/<name> 目录并不能证明依赖项不可用——技能目录会在调用时解析技能，这种情况很正常。

仅运行一次此检查，静默执行，仅供自己了解——绝不要将其作为本次运行面向用户的首条输出：

for skill in agentforce-generate dx-org-permission-set-assign service-digital-engagement-channel-configure service-digital-engagement-deployment-configure experience-lwr-site-generate service-digital-engagement-messaging-site-integrate service-concierge-portal-generate service-agentforce-channel-configure; do
  [ -d ".claude/skills/$skill" ] && echo "OK: $skill" || echo "resolve-at-runtime: $skill"
done

**不要停止，也不要以逐一通报缺失依赖项作为本次运行的开场。**继续执行各检查点；只有在流程实际到达某个同级技能时，才委托给它。如果——且仅当——实际到达委托步骤时无法解析该特定技能，则在此时指出该技能的名称。绝不要提前将完整的八项技能清单作为交付内容；这不是由用户决定的事项，也不是报告内容。

---

工作流

先阅读 assets/help-agent-spec.md——这是权威流程，内容刻意保持精简。**不要预先加载其余内容。**较长或有条件的材料拆分在 references/ 中，仅在流程到达相应环节时才读取（渐进式披露——这是刻意安排的，以降低令牌用量）：

• references/agent-script.md — 约 500 行的规范 Agent 脚本及占位符列表。仅在准备创建 Agent 时，也就是检查点 2 之后加载——不要在检查点 1、3 或 4 加载。
• references/channel-web-chat.md — Web Chat 配置详情。仅当用户在检查点 3 选择 Web Chat 时加载。
• service-concierge-portal-generate — Help Portal / Agentforce Concierge 门户部署。若用户在检查点 3 选择 Help Portal，请委托给此技能——不要在此处内嵌门户操作手册步骤。将 $ORG、$BOT_ID 和 $BOT_DEV_NAME 作为上下文传递，以便该技能跳过自身的入口问题。
• references/channel-voice.md — 语音渠道接线详情（仅限现有号码）。仅在用户选择 Voice 时加载。

只读取与用户选择相符的渠道文件——绝不要全部读取。然后执行交互式设置，不要一次性完成：按顺序引导用户完成四个检查点，并在每个检查点等待回复。

就绪检查（静默执行，MANDATORY，不得调整顺序）

顺序至关重要 — 在步骤 2 之前运行步骤 3 会失败，并显示 PermissionSet not found: GenieUserEnhancedSecurity，因为只有在 Data Cloud 本身启用后，Data Cloud 权限集才会在组织中创建：

1. 先确认 PSL 席位可用，再为此 Agent 创建专用 Einstein Agent User。 首先确认以下三个必需的 PSL 有可用席位：

   sf data query --target-org $ORG --json \
     --query "SELECT MasterLabel, TotalLicenses, UsedLicenses FROM PermissionSetLicense WHERE DeveloperName IN ('AgentforceServiceAgentUserPsl', 'GenieDataPlatformStarterPsl', 'EinsteinGPTPromptTemplatesPsl')"
   

   对于每个 PSL，UsedLicenses < TotalLicenses 必须为 true。如果任一 PSL 已满，请停止并指出哪个 PSL 已无可用席位 — PSG 分配将失败，在释放或配置席位之前，此技能无法进行任何操作。

   如果三个 PSL 都有可用席位，请创建用户。不要重复使用任何现有的 Einstein Agent User — 每个 Help Agent 都需要自己的用户。用户名：{agentDevName}_user@{orgId}.ext（通过 sf org display 获取 15 位 org Id）。邮箱：[email protected]。配置文件：Einstein Agent User（查询 SELECT Id FROM Profile WHERE Name = 'Einstein Agent User' 获取 ProfileId，然后运行 sf data create record --sobject User）。如果已存在用户名完全相同的用户，则重复使用该用户（幂等）。然后在发布 Agent 之前分配以下全部四项：

   • AgentforceServiceAgentUserPsg（Permission Set Group）— 一次性分配三个 PSL：Agentforce Service Agent User、Data Cloud 和 Einstein Prompt Templates。使用 sf org assign permsetgroup。
   • AgentforceServiceAgentSecureBase（Permission Set）— 所有服务 Agent 都必需。使用 sf org assign permset。
   • AgentforceKnowledgeUser（Permission Set，force 命名空间）— Help Agent 使用 knowledge: 块，因此此项必需。使用 sf org assign permset。
   • {AgentName}_Access（自定义 Permission Set）— 由 agentforce-generate 创建，用于 Agent 专属的 Apex/对象访问权限。

   验证 PSL 分配已生效：SELECT PermissionSetLicense.DeveloperName FROM PermissionSetLicenseAssign WHERE Assignee.Username = '{agentDevName}_user@{orgId}.ext' — 预期结果为 AgentforceServiceAgentUser、DataCloud、EinsteinPromptTemplates。

   记录用户名（{agentDevName}_user@{orgId}.ext）— 这是 Agent 脚本中 <default_agent_user_placeholder> 的值。Agent 在运行时以此用户身份运行。

   发布前检查 — 每次调用 sf agent publish authoring-bundle 之前都要验证。 跳过此检查会导致经过掩盖的 401→404：缺少 AgentforceServiceAgentUserPsg 的 Einstein Agent User 会使 SFAP 返回 HTTP 401「用户无权访问 Agent」，而 jsforce 的会话刷新重试会悄然将此 401 转换为 ERROR_HTTP_404。调用 CLI 之前，请确认四项分配均已生效：

   AGENT_USER_ID=$(sf data query --target-org $ORG --json \
     --query "SELECT Id FROM User WHERE Username='{agentDevName}_user@{orgId}.ext'" \
     | python3 -c "import sys,json; print(json.load(sys.stdin)['result']['records'][0]['Id'])")
   
   # Must return exactly 1 row — if 0, assign before continuing
   sf data query --target-org $ORG --json \
     --query "SELECT PermissionSetGroup.DeveloperName FROM PermissionSetAssignment \
              WHERE AssigneeId='${AGENT_USER_ID}' \
              AND PermissionSetGroup.DeveloperName='AgentforceServiceAgentUserPsg'"
   
   # Must return 2 rows — if any are missing, assign before continuing
   sf data query --target-org $ORG --json \
     --query "SELECT PermissionSet.Name FROM PermissionSetAssignment \
              WHERE AssigneeId='${AGENT_USER_ID}' \
              AND PermissionSet.Name IN ('AgentforceServiceAgentSecureBase','AgentforceKnowledgeUser')"
   

   在四项分配均返回非空结果之前，不要调用 sf agent publish authoring-bundle。

2. 启用 Data Cloud — 必须在步骤 3 之前完成（Data Cloud 启用之前，权限集尚不存在）。如果尚未配置 Data Cloud，请预先让用户选择：现在启用，稍后再继续；或现在等待整个过程完成。

3. 关键 — 启用后立即分配 Data Cloud 权限集。 这是不可妥协的要求 — 跳过此步骤会导致 Agent 上线后，运行时的 grounding 返回空的 knowledgeSummary，即使 ADL 索引报告 SUCCESS 也是如此。步骤 1 中分配的 PSG 会在 Data Cloud 启用后涵盖此项。

识别用户从哪里开始

检查点 1（Agent 身份）和检查点 3（渠道）必须始终在当前对话中向用户确认，绝不能根据之前的会话、压缩后的摘要或技能参数推断。 这些决定由用户掌握；沿用之前运行中的过时上下文，会配置错误的 Agent 或渠道。

如果用户在当前对话轮次的开场消息中明确指出 Agent 和／或渠道（例如“在 Web Chat 上设置 Master Yoda”），则接受这些信息作为输入，并在继续前予以确认。若当前轮次中未说明，则应询问。

对于组织别名：如果用户在当前会话中一直使用某个特定组织，则使用该组织。否则应询问。

不要假定每次运行都从检查点 1 开始。 阅读开场提示，并从正确的检查点开始：身份已确定 → 检查点 2（依据）；依据已完成 → 检查点 3（渠道）。如果提示明确指出或暗示要从后续检查点开始（例如“设置依据”“接入 Web Chat 渠道”），且说明或清楚暗示之前的检查点已完成，则接受之前的检查点已确定，从指定检查点开始处理，并提供该检查点的已确定事实报告。不要强制重新引导用户确认身份，不要从检查点 1 重新开始，也不要要求用户在当前对话中重新确认之前的决定。提示中为当前检查点提供的值（受众 → authMode、指定站点、类别）均视为已确定，不要再次询问。

如果开场提示提到 Voice / 电话 / 电话通信 / IVR，请阅读 references/channel-voice.md，并从检查点 3 的开头按 Voice 分支处理。

检查点 1 — 认识你的 Agent

询问以下四项（请提供这些确切的默认值，以便引导式决策报告无需加载 assets/help-agent-spec.md 即可列出它们）：

1. Agent 名称 — 默认值为 Help Agent（DeveloperName Help_Agent）。
2. 语言 — 默认值为 en_US。
3. 欢迎语 — 默认值为 "Hi, I'm {Agent Name}. How can I help you today?"。
4. 语气 — 默认值为 "calm, patient, friendly service agent — warm but professional, short sentences, never robotic."

当开场提示提到问答／案例管理／人工升级时，明确说明这些内容对应规范的四个子 Agent 结构（Agent Router → General FAQ、Service Customer Verification、Case Management、Escalation）——不要另行设计不同的方案。

检查点 2 — 为 Agent 提供上下文（grounding）

询问使用哪种知识来源（Salesforce Knowledge／文件／网站同步）。Grounding 是配置 Agentforce Data Library，而不是设计搜索；Agent 的 knowledge: 块会在运行时执行检索。此检查点必须完成以下全部五项：

1. 将配置工作委托给 agentforce-generate — 它负责创建、索引和发布 ADL。不要手动编写数据库元数据。
2. 创建专用且有名称的库 — 创建 Help_Agent_Knowledge。绝不要接入现成的 All_Records_and_Fields_Default（在试用版或预加载示例数据的组织中，它会处于 NOT_SCHEDULED 状态，并返回空的 knowledgeSummary，且不报错）。
3. 选择类别 — 对于 Salesforce Knowledge，查询组织的 Data Category Groups。仅在交互式运行中询问要基于哪些类别；对于非交互式／限定范围的运行，确定合理的默认值（组织的默认 Data Category Group；如果未指定，则使用所有组），并在已确定事实报告的 Blocking Issues 行中明确注明该默认值（例如：“未指定 Knowledge 数据类别 — 选择了组织的默认组”）。不要停下报告等待答复。
4. 设置等待索引的关卡 — 轮询，只有当 indexingStatus.status ∈ {COMPLETED, READY, SUCCESS} 时才继续。NOT_SCHEDULED 不代表成功。
5. 记录 rag_feature_config_id（格式为 ARFPC_<libraryId>），并将其接入 Agent 脚本的 knowledge: 块 — 绝不要硬编码。

**反规则：**绝不要通过设计针对 Knowledge 文章的 SOQL/SOSL/GraphQL/Apex 搜索来响应 grounding 请求。Grounding 是配置 ADL；检索由 Agent 在运行时负责。

检查点 3 — 添加到渠道

首先，始终先查明现有内容 — 绝不要只把 Web Chat／Help Portal／Voice 列出来，仿佛它们是仅有的选项。 完整遵循 assets/help-agent-spec.md §4.3 Step 1：查询每个 MessagingChannel，按 <messagingChannelType> 分类，并列出所有存在的类型（WhatsApp、SMS 等），而不只是下面三个分支。此部分旨在防止跳过此发现步骤。

使用队列路由部署新渠道（service-digital-engagement-channel-configure），然后将 Agent 接入工作委托给 service-agentforce-channel-configure。按渠道类型分支：

• Web Chat → 阅读 references/channel-web-chat.md。创建 messaging channel 和 Embedded Service Deployment。先询问部署目标，再查询任何内容：“自有（非 Salesforce）网站”（建议的默认选项 — 可直接采用嵌入代码片段路径）或“Salesforce Experience Cloud 站点”。仅当用户选择 Experience Cloud 时，才执行先查询模式：

  SELECT Id, Name, UrlPathPrefix, SiteType, Status
  FROM Site
  WHERE SiteType IN ('ChatterNetworkPicasso', 'ChatterNetwork') AND Status = 'Active'
  

  LWR（ChatterNetworkPicasso）和 Aura（ChatterNetwork）站点都支持 experience_messaging:embeddedMessaging 小组件。过滤掉以 ESW_ 开头的站点（这是内部 ESD 脚手架，并非真正的 Experience Cloud 站点）。在同一轮中确定站点，不要延后处理：

  • 没有真实站点 → 通过 experience-lwr-site-generate 创建一个（建议使用 Help Center 模板），或回退到“部署到我的网站（获取代码片段）”。
  • 恰好一个 → 使用前先向用户确认（现有站点可能面向不同受众）；不要擅自采用。
  • 多个 → 在同一轮中展示已执行的 SOQL，以表格形式列出结果（Name | Type | UrlPathPrefix），说明“在你选择之前，不会创建或修改任何站点”，然后询问要使用哪个站点（提供“创建新 LWR 站点”和“部署到我的网站”选项）。不要用“我稍后回复”拖延 — 立即展示结果。

  不要按硬编码的名称或 URL 路径前缀筛选 — 正确的站点取决于客户的组织。

• Help Portal → 委托给 service-concierge-portal-generate（在 LWR 站点上部署 Agentforce Concierge 体验）。传入已解析的 $ORG、$BOT_ID 和 $BOT_DEV_NAME，以便跳过其入门问题。

• Voice → 阅读 references/channel-voice.md 并完整遵循。通过 service-agentforce-channel-configure Branch B 接入一个 PstnVoice MessagingChannel；如果不存在，该引用会将采购委托给 service-agentforce-contact-center-coordinate。

• 任何其他现有渠道（WhatsApp、SMS、Facebook、Apple Business Chat、Line、Email-to-Case、Custom） → 没有专门的引用文件。从发现结果中列出该类型的渠道，让用户选择一个（"Add agent to: {MasterLabel}"），并直接委托给 service-agentforce-channel-configure，同时传入 Agent 和渠道的 DeveloperName —— 它会自行解析回退队列并选择路由分支（增强型 Chat/Messaging 使用 Branch A，Email-to-Case 使用 Branch C）。此 Skill 只将 Agent 接入已存在的渠道；它从不配置底层的第三方/电子邮件基础设施。

每个渠道分支完成后，循环 —— 询问用户是否想添加另一个渠道。 一旦某个渠道分支结束（成功或失败），通过 AskUserQuestion 呈现：

• 添加另一个 [相同类型] 渠道 —— 提供该类型剩余的未接入渠道；重新运行该分支，跳过本次会话中已接入的渠道。
• 添加不同的渠道类型 —— 返回 Checkpoint 3 开头（重新查询 MessagingChannel，重建类型列表，从选项中省略已接入的渠道）。
• 完成 —— 继续 go-live —— 退出循环并进入 Checkpoint 4。

跟踪已接入的渠道，使其不再被重复提供；循环持续进行，直到用户选择 "Done" 或所有渠道都已接入。

出站升级在此处接入，紧接在入站路由之后，而不是在 Checkpoint 4。 对于 Web Chat/Voice 分支，在与入站路由相同的委托调用中调用 service-agentforce-channel-configure Phase 3（解析升级队列 → 创建/复用 RoutingFlow → 添加连接块 → 重新发布）。将连接块接入推迟到 Checkpoint 4 会重复 Phase 3 的原子化顺序，并强制进行一次额外的重新发布。

当开场提示词一开始就点明两个或更多渠道时（例如 "add web chat, then also Voice — add both"），该提示词授权了每一个被点名的渠道 —— 将它们全部视为已承诺的工作。从一个被点名的渠道推进到下一个时，无需用户新的回复；开场请求 本身就是 该授权。对于提示词中点名的渠道，跳过分支之间的 AskUserQuestion，按所述顺序接入每一个，仅对提示词 未 点名的渠道回退到循环的 AskUserQuestion。报告必须显示每一个被点名的渠道都已接入 —— 绝不能只显示第一个，而将其余的表述为意图或 "next step"（即使第一个渠道完美无缺，这也会被判定为不完整的循环）。在已确定事实的 Checkpoint 3 行中（或表格下方的简短追踪中），按顺序明确列出以下所有内容：

1. 第一个渠道的完成 作为已确定事实（渠道类型、Web Chat 的 authMode、解析出的站点/号码、ESD 状态）—— 而不是 "will then add"。
2. 继续的授权：提示词点名了下一个渠道，因此流程在没有任何分支之间提示的情况下推进。绝不报告未发生的用户回复 —— 对于提示词点名的渠道，声称用户 "continued after an AskUserQuestion" 是捏造交互并违反契约。
3. 后续渠道的进入：流程为每个下一个被点名的渠道重新进入 Checkpoint 3，每个都推进到其自身的已确定结果。仅当确实运行了分支之间的提示时才报告其选项和选择（即提示词 未 点名的渠道）。
4. 只有在每一个被点名的渠道都已接入（或因一行原因被阻塞）之后，流程才到达 go-live。

检查点 4 — 审核并上线

频道循环退出（“Done”）后，运行两个阶段（下方的阶段 A 原为独立的“检查点 3.5”）：

阶段 A — 静默预检（内部操作 — 切勿对外宣布）。 静默运行；仅在失败时显示输出。阶段 B 开始前，每项检查都必须通过：

1. 正在运行的用户和Einstein Agent User 均已获得 Data Cloud 访问权限（交由 agentforce-generate 处理）。
2. ADL 已激活且已完成 grounding — 使用捕获的 rag_feature_config_id 运行一次 canary 检索；如果结果为空但状态为 SUCCESS，则逐字显示已知的手动步骤（权限集上的 Data Space 范围），等待确认后重新运行。
3. Messaging 频道处于活动状态（进行断言；初始激活由 channel-configure 技能负责，而非 site-integrate 技能）。流程只有在此处检查或设置频道活动状态 — 阶段 B 不会重复此操作。

阶段 B — 明确的上线步骤（向用户说明）。 验证小组件已放置到网站上（LWR + Aura）— 放置已在检查点 3 的步骤 C.5 通过 service-digital-engagement-messaging-site-integrate 完成；仅在验证失败时重新注入。然后：(a) 确认已连接升级流程（已在检查点 3 的阶段 3 配置 — 只需验证，不要重新连接）；(b) 在 Setup → Embedded Service Deployments 中发布 Embedded Service Deployment；然后提出一起测试。未发布的部署会悄无声息地上线一个无法使用的小组件。

规则 / 约束

长列表展示规则

AskUserQuestion 最多支持 4 个选项。对于用户需要从已发现的项目列表（站点、渠道、队列、ADL）中选择一项的情况：1–6 个项目 — 每页显示 3 个选项，第 4 个选项为“显示更多（剩余 N 项）”，固定选项（创建新项目等）仅出现在最后一页。7 个及以上项目 — 以纯文本列出名称，让用户输入选择，并进行不区分大小写的验证，继续操作前先确认。

例外 — 多选列表（例如 Checkpoint 3 的渠道类型选择器）绝不分页。 分页适用于单选。对于任何多选列表，选项超过 4 个时，无论数量多少，都应直接改用纯文本列表并让用户输入的模式 — 请参阅 assets/help-agent-spec.md §4.3 Step 1。

规则	原因
绝不一次性完成设置	这是引导式对话；在每个检查点都要等待用户输入
绝不跳过或调整准备步骤的顺序	启用 Data Cloud 之前不会创建权限集 — 你会看到 PermissionSet not found: GenieUserEnhancedSecurity
绝不在 ADL 检索结果为空时越过 Checkpoint 4 Phase A	这会部署出一个悄然失效的 Agent
绝不对站点名称或 URL 路径前缀进行硬编码	正确的目标 LWR 站点取决于客户的组织 — 先查询，再决定
绝不将 ESW 前缀站点作为 Widget 部署目标展示	ESW_* 站点是内部 ESD 端点脚手架 — 在向用户展示站点选项前，须在后处理中将其过滤掉
始终通过 Connect API 将 Embedded Service Deployment 创建为 V2，绝不直接通过 Metadata 部署 — 并通过 experience_messaging:embeddedMessaging LWR 组件嵌入 V2 ESD	Metadata API 默认使用旧版 V1（WebV1，Setup 中显示为 "Web (v1)"），这会导致 Enhanced Web Chat 无法正常工作；请在 v67.0+ 上通过 Connect API 并使用 clientVersion: WebV2 创建。客户 Widget 通过以 deploymentName 为键的 LWR 组件挂载。完整的六属性结构、Tooling API 修补路径和访客浏览器验证方法见 references/channel-web-chat.md
始终为 Help Agent 创建专用 ADL — 绝不连接现成的 All_Records_and_Fields_Default 库	在试用版或预加载示例数据的组织中，现成库会卡在 NOT_SCHEDULED 状态且永远不会建立索引；将 Agent 连接到该库会导致运行时 knowledgeSummary 为空，且没有可见错误。请在 Checkpoint 2 创建 Help_Agent_Knowledge，并等待 indexingStatus ∈ {COMPLETED, READY, SUCCESS} 后再连接
离开 Checkpoint 4 前，绝不在未发布 Embedded Service Deployment 和激活渠道的情况下结束	Widget 必须同时满足这两个条件才能提供服务。如果通过 Connect API 的 deployment/setup 调用创建了 ESD，则它已经发布 — 请确认已标记 "Published on:"，且标题不带 (v1) 后缀
Web Chat、Help Portal 和 Voice 有专用分支；任何其他现有渠道类型（WhatsApp、SMS、Facebook、Apple Business Chat、Line、Email-to-Case、Custom）均通过 service-agentforce-channel-configure 进行通用连接	发现步骤（§4.3 Step 1）必须列出所有现有渠道类型 — 存在其他类型时却只提供三个专用分支，正是此检查点要防范的问题。对于 Web Chat，始终运行部署后断言（重新获取 MessagingChannel，并断言 embeddedConfig.authMode；默认值为 UnAuth）— 选错会导致部署出的 Widget 对访客无法显示，且不会发出提示。将 authMode 作为纯值报告（authMode: UnAuth）；不要叙述断言过程。绝不输出旧版 esw.min.js / Live Agent V1 代码片段

输出要求

唯一交付物是一个 report.md：记录已决定事项和已完成工作的状态报告，而非设计文档。有两种形式——当流程执行了某个步骤时，使用已确定事实报告（在表格中列出具体的已决定值）；当流程停留在由用户决定的事项上时，使用引导式决策报告（列出选项，不要编造）。决策单元格中绝不能使用含糊表述（如“待记录”“待定”“将创建”）；绝不能编造不透明 ID；绝不能在请求未涉及的检查点上虚构阻碍因素。完整模板、各形式的规则、单项决策推理说明（就绪顺序、authMode），以及“绝不能包含”的评分失败清单，都在 references/output-report-format.md 中——撰写报告前请先阅读。

参考文件索引

文件	阅读时机
assets/help-agent-spec.md	始终阅读（首先阅读）——规范流程；有意保持简短，并指向以下文件
references/agent-script.md	仅在创建 Agent 时阅读（检查点 2 之后）——规范 Agent 脚本及占位符
references/channel-web-chat.md	仅当用户在检查点 3 选择 Web Chat 时阅读
service-concierge-portal-generate（外部技能）	仅当用户在检查点 3 选择 Help Portal 时使用——委派处理，不要内联
references/channel-voice.md	仅当用户选择 Voice 时阅读（接入 PstnVoice 渠道；若尚无该渠道，则委派采购）
references/output-report-format.md	即将撰写最终 report.md 时阅读——两种报告形式、模板及评分失败清单