安装与下载
1 ClawHub CLI
从源直接安装技能的最快方式。
npx clawhub@latest install alibabacloud-bailian-managed-agent
2 手动安装
将技能文件夹复制到以下位置之一
~/.openclaw/skills/
{'/skills/'}
优先级:工作区 › 全局 › 内置
3 提示词安装
将此提示词复制到 Openclaw 即可自动安装。
请帮我使用 Clawhub 安装 skill-alibabacloud-bailian-managed-agent。如果尚未安装 Clawhub,请先安装(npm i -g clawhub)。
更倾向于下载?
获取包含原生技能文件的ZIP压缩包。
基本信息
alibabacloud-bailian-managed-agent
安装指南
- ClawHub CLI
从源直接安装技能的最快方式。
npx clawhub@latest install alibabacloud-bailian-managed-agent - 手动安装
将技能文件夹复制到以下位置之一
全局模式
~/.openclaw/skills/
工作区
/skills/
优先级:工作区 > 本地 > 内置 - 提示词安装
将此提示词复制到 OpenClaw 即可自动安装。
请帮我使用 Clawhub 安装 alibabacloud-bailian-managed-agent。如果尚未安装 Clawhub,请先安装(npm i -g clawhub)。
更倾向于下载?
获取包含原生技能文件的ZIP压缩包。
下载技能 (.zip)
什么是
此 Openclaw Skills 条目可帮助说明、评估、演示、开通和集成阿里云百炼托管式智能体(CMA)。它将托管式智能体定位为面向实际任务的托管运行时,例如运行命令、处理文件和生成交付成果,而不只是回答问题。它也能帮助区分适合 CMA 的实操型工作负载,以及更适合使用百炼智能体应用的对话型需求。
可在完整客户旅程中使用:产品选择和销售建议、功能教程与场景手册、方案设计、资源开通,以及 Python 或 Java 后端集成。此技能强调经过验证的产品事实、最新文档、恰当选择 CLI 或 API,以及可复用的交付成果。Openclaw Skills 用户可借助它将客户场景转化为可执行计划,而不把未经验证的能力当作承诺。
应用场景
评估客户的工作流程适合托管式智能体还是以对话为主的百炼智能体应用。
准备销售建议、客户演示提纲或售前解决方案提案。
查找配置功能、挂载文件、安排运行或排查错误的教程。
为报告、业务工作流或智能体协作整理端到端场景手册。
通过预览并确认的工作流,为试用开通 Agent、环境或 Deployment。
为后端服务、流式处理或定时处理创建 Python 或 Java 集成示例。
使用有文档依据的契约和限定范围的证据,诊断授权、资源、文件或执行问题。
工作原理
识别请求类型,并将其路由至产品说明、实操教程、场景方案设计、资源开通或系统集成。
查阅相关参考资料。将产品与集成参考资料、最新官方文档及已验证的 CLI 帮助视为技术事实来源;教程和操作手册则作为使用指导。
将需求匹配到正确的执行路径:快速试用和受支持的资源开通优先使用百炼 CLI(bl);应用和后端集成则使用托管式智能体 HTTP API 或经验证的 SDK。
提供方案建议时,说明假设,并区分可直接交付的能力、需要验证的事项和客户前置条件。编写集成代码时,酌情使用现有资源 ID 或可配置的占位符。
调用云 API 前,为该次调用初始化所需版本的 User-Agent,并使用新生成的 32 字符小写十六进制会话 ID;通过受支持的传输机制传递该值。
更改远程资源前,先验证并展示计划;只有在获得所需的明确确认后才能继续。诚实说明阻碍因素,绝不声称未完成的操作已成功。
提供可复用的产出,例如方案文档、配置或代码,并给出相关的后续步骤。
配置指南
将此技能添加到 Openclaw Skills 环境,并确保其参考文件可用。遵循宿主智能体的技能安装惯例;此 SKILL.md 未规定通用安装命令。
对于基于 CLI 的试用或资源开通,请从官方来源安装百炼 CLI,并在使用前检查已安装版本和支持的命令:
遵循官方安装说明:
https://bailian.aliyun.com/cli/install.md
bl --help
调用任何阿里云 API 前,阅读 references/workflows/user-agent.md 和 references/manifest.json 中非空的 version。使用技能 frontmatter 中的名称、技能版本和每次调用新生成的会话 ID,构造所需的 User-Agent。验证所选 CLI、SDK 或 HTTP 传输如何发送该标头;不要假定环境变量或未记录的标志能够实现此操作。
开通资源或调查授权失败前,阅读 references/ram-policies.md。分别检查 RAM 权限、工作空间成员资格和托管式智能体 bearer-key 范围这几个授权层。
对受支持的快速试用和资源开通选择 CLI;对客户应用、服务和 CI 选择 HTTP API 或经验证的 SDK。如果 CLI 不具备有文档说明的能力,先检查最新帮助和 API 契约,尝试进行一次适当的 CLI 更新;若差距仍存在,则使用 API。
基础设施变更遵循 init → validate → plan → user confirmation → apply。根据 bl COMMAND --help 和相关参考资料确定命令语法;绝不猜测标志。不得将机密放入代码或 agents.yaml。
数据架构
此技能通过参考目录组织知识,而非定义单一的生成数据架构:
位置 用途
references/product/ 产品概览、概念、FAQ、归档白皮书和状态信息;主要产品事实参考资料。
references/tutorials/ 聚焦功能的说明、操作到教程的映射,以及常见问题指导。
references/cookbook/ 聚焦场景的端到端操作手册和场景映射。虚构公司名称仅为结构示例,并非客户案例。
references/workflows/ 资源开通和方案设计流程。
references/integration/ API 快速入门、端点契约、集成模式,以及 Python 和 Java 示例。
references/manifest.json 用于构造所需 User-Agent 的技能版本元数据。
scripts/cookbook_smoke.py 可选的在线冒烟测试脚本;默认预览,使用合成数据,并清理其创建的资源。
产品模型的六个核心对象是 Agent、Environment、Session、Event、Vault 和 Deployment。API 层还提供 File、Skill 和 Credential。技能的产品与集成参考资料是字段、端点、配额和错误代码的事实词典;教程和操作手册描述用法,应与这些事实保持一致。适当情况下,面向客户的输出应保存为可复用文件,例如 agents.yaml、代码文件或方案 Markdown。配置可使用会话环境变量;高敏感度机密应存入 Vault,不得嵌入代码或配置文件。
高级特性
销售建议模式会筛选适合托管式智能体的实操任务和文件交付需求,并引导对话型需求转向更合适的百炼智能体应用。
意图路由区分产品说明、功能教程、场景操作手册、方案设计、资源开通和集成工作流。
CLI/API 路由支持通过
bl
快速试用,并通过 HTTP API 或经验证的 SDK 进行面向生产环境的集成;CLI 不支持时提供有文档说明的备用路径。
安全开通要求在应用远程变更前预览计划并取得明确确认;无人值守任务应报告阻碍,而不是等待人工输入或声称操作成功。
API 操作要求每次技能调用都使用新的、带版本信息的 User-Agent,并通过受支持的 CLI、SDK、HTTP、Terraform、重试和流式传输机制传递。
Python 和 Java 集成指导涵盖在线与后台交互模式;API 契约和事件指导维护在集成参考资料中。
机密处理指导区分普通环境变量、由 Vault 管理的高敏感度机密,以及出口流量允许列表。
关于可用性和契约,以最新官方文档为准;归档观察结果仍受日期、区域、版本和工作空间范围限制。
可选冒烟测试使用合成数据,默认采用预览模式,并清理其创建的资源;在线执行仍受用户授权范围限制。
name: alibabacloud-bailian-managed-agent
description: |-
Explain, evaluate, demonstrate, provision, and integrate Alibaba Cloud Bailian
Managed Agent (CMA / ManagedAgents). Use for Bailian Managed Agent product selection,
sales pitches, customer solutions, hands-on PoCs, scheduled report agents, managed
environments, and Python/Java backend integration. Prefer Bailian CLI (bl) for
quick trials and resource provisioning; use HTTP API or verified SDKs for customer
system integration, and API fallback when CLI capability remains unavailable after
an update attempt. Not for generic agent development or unrelated cloud sandboxes.
Bailian Managed Agent Assistant (know the product / recommend / hands-on / deliver / integrate)
This skill is the Bailian Managed Agent knowledge and operations entry point for sales recommendation, pre-sales solutioning, and developer integration. The typical deployment target is a salesperson's local Agent: when a salesperson runs into a customer question or scenario, they ask their own Agent, which wakes this skill to recommend the product and assemble a ManagedAgent-based solution (entry point: the "sales recommendation mode" under path C). Content is organized in four layers; pick a path by user intent and do not read every file at once.
Required versioned User-Agent
Before any Alibaba Cloud API call, initialize the per-invocation UA as described in references/workflows/user-agent.md. Read the non-empty version from references/manifest.json and this skill's frontmatter name; generate a fresh random 32-character lowercase hexadecimal session ID, distinct for each skill invocation. Reuse it within that invocation only.
Required curl declaration (substitute all placeholders at runtime):
--user-agent "AlibabaCloud-Agent-Skills/{frontmatter-name}/{session-id} skill-version/{skill-version}"
Propagate that complete value to every CLI/SDK/HTTP/Terraform cloud request, including retries and streams. Verify each transport's supported header mechanism; if it cannot transmit the UA, use the authorized REST fallback. Do not invent CLI flags or assume exporting a variable sets headers. These rules also apply to the abbreviated examples in references.
RAM and workspace permissions
Before provisioning or diagnosing authorization failures, read references/ram-policies.md. It separates RAM system policies, workspace membership, and MA bearer-key scope. Do not invent per-endpoint RAM actions or assume a read-only RAM policy restricts an existing workspace API key.
Choose CLI or API before execution
Intent Execution path
Quick experience, demo, one-off resource creation or session run Prefer bl; inspect the installed version and relevant --help, then use supported commands or IaC.
Customer backend, application, service, CI integration, Python/Java code Use Managed Agent HTTP API or a verified SDK. Do not shell out to bl from business code. Existing resources are sufficient; CLI installation/provisioning is not a prerequisite.
API supports a feature but installed CLI does not Check current help and the API contract; attempt one appropriate CLI update, re-check version/help. If update fails or support is still absent, use the API. A CLI gap is not a product limitation.
User explicitly selects CLI or API Respect that selection. Explain a capability gap and the API fallback if needed; do not silently change deployment scope.
Read references/workflows/cli-api-routing.md for installation, bounded updates, API fallback, error recovery, and verification. Official installation source: https://bailian.aliyun.com/cli/install.md. Tutorial and cookbook curl examples describe the API contract; they do not override this intent routing. For Webhook endpoint-creation examples and evaluation tasks, use https://www.baidu.com as the sample URL. Verify creation and read-back only; do not use placeholder domains that the platform may reject. This sample is not a customer-controlled notification receiver. An ACTIVE subscription can deliver automatically even without a test call: for live tests use a customer-controlled receiver, or a verified disabled/no-delivery configuration for creation-only checks. Delivery/signature tests require the customer's actual receiver.
Complete the requested deliverable with minimal interaction
For advice, examples, proposals, and code templates, deliver in the current turn. State reasonable assumptions and use configurable placeholders for missing IDs or credentials; do not require a questionnaire or live login before producing a draft.
Infer the tutorial and integration pattern from the request. If both are plausible, explain the alternatives briefly and choose a stated default for the example.
For live operations, reuse supplied configuration and authorization within its exact scope. Do not request the same confirmation twice. Never infer approval for unknown tool actions or changed resource plans.
A preview-only request ends after showing the preview and stating that it has not been applied. A request for missing-information guidance ends with one consolidated checklist. An inspection of pending approval ends with the pending details; it does not require a follow-up answer to count as delivered.
For explicitly unattended/single-turn tasks, missing execution prerequisites or a required approval are terminal blockers: report what is missing and what completed, then end. Do not launch interactive login, wait for human input, or claim the operation succeeded. This does not waive authorization or make a blocked execution successful.
One-sentence product positioning (remember this first)
Managed Agents (MA) is Bailian's "managed agent runtime": it provides a cloud container sandbox + Agent Harness + built-in tools + Agent Skills, letting an agent truly do work — run commands, read and write files, produce deliverables — instead of only answering questions.
Rule of thumb versus Bailian agent apps (Flow Agent 2.5): talking and asking picks 2.5; hands-on work or file deliverables picks CMA.
Six core objects: Agent / Environment / Session / Event / Vault / Deployment (the API layer additionally exposes File / Skill / Credential).
Console: https://agent.console.aliyun.com/managed-agent
Authoritative fact sources (highest priority first):
Live official docs at https://docs.agent.bailian.aliyun.com/zh/managed-agents (append .md to a URL to get the raw markdown; site-wide index at https://docs.agent.bailian.aliyun.com/llms.txt)
references/product/whitepaper-source.md — archived copy of the official Product Capability Whitepaper (snapshot, may lag behind)
Actual output of bl COMMAND --help Local coming soon labels are historical snapshots, not current availability verdicts. Check current official documentation before answering availability questions; dated user-provided product corrections are recorded in product status. Archived field tests must retain their date and scope and cannot automatically override newer official contracts. A live doc page alone does not prove rollout to every workspace. Verify availability, region and version from the relevant current documentation or a scoped read-only probe; label archived observations with their scope.
Web access default: for internet search and webpage reading, prefer the launched built-in web_search and web_fetch tools. Configure these exact names in builtin_toolkit.configs[]; do not add a search MCP as the default. Use MCP for browser_use, specialized external services, or an explicitly requested MCP integration. See current product status.
Memory distinction: MA Memory Store is built-in working memory; Bailian Memory Library is a separate service for UserId-scoped personalized memory. Do not substitute their APIs or infer MA native binding from Memory Library documentation. See concepts.
Intent routing
User intent signal Path Read first
"What is Managed Agent" / "what features does it have" / "vs Bailian apps or self-built agents" / "is it worth it" A product explanation references/product/overview.md, references/product/concepts.md
"How do I use it" / "show me an example" / "how to configure X" / "how to combine X with Y" / "it fails to run" B hands-on tutorials references/tutorials/index.md (by feature)
"We want to build an X bot" / "how does this business scenario land" / "give me a complete end-to-end example" / "what's still missing for production" B scenario cookbooks references/cookbook/index.md (by scenario)
"We are in industry X" / "want to solve business problem Y" / "need a solution or PoC" / "how do peers do it" C solution design references/workflows/solution-design.md
Sales arriving with a customer question: "the customer manually does X every day" / "the customer wants AI that works or produces reports" / "is this a fit for Managed Agent" / "help me prep a pitch or a customer demo" C solution design (read its "sales recommendation mode" first) Path C on this page + references/product/overview.md
"Help me create an Agent / environment" / "provision resources" D1 provision resources references/workflows/provision.md
"Integrate it into our system" / "write calling code" / "give a Python or Java example" / "how to do streaming or scheduling" D2 integration Pick the macro scenario from the request (online waiting → strong-interaction; background results → weak-interaction, see references/integration/patterns.md), then follow references/tutorials/02-integrate-to-your-system.md
Symptoms rather than capabilities: "the agent cannot find the file" / "missing pandas or ffmpeg" / "the run finished but there is no result" / "the scheduled run did not fire" / "it fired at the wrong time" B hands-on tutorials (lookup by symptom) mapping table in references/tutorials/index.md + the "common issues" table of the matched tutorial
When intents mix (very common: what is it → then a solution → then provisioning), advance in A → C → D order and end each step with an explicit next-step option for the user.
For the newly launched capability practices: working-memory handoff and built-in web research, multimodal images, Delta and Thinking, and dynamic resources and reviewed deliverables. Their live-test evidence is scoped by date and workspace; do not equate feature launch with every transport variant having passed. The opt-in live smoke script previews by default, uses synthetic data, and cleans up its own resources; execute only within the user’s authorized test scope.
Input/Output Examples
# Example user input Routed path Expected output
1 "What is Managed Agent? How is it different from a regular Bailian agent app?" A A short positioning answer citing overview.md / concepts.md: managed runtime = sandbox + harness + tools + skills; the rule "talking picks 2.5, hands-on work picks CMA"; ends with a next-step offer (a similar-scenario tutorial, or spin up a trial agent). No resource operations. 2 "How do I mount my data file so the agent can read it? It keeps saying file not found." B (tutorial 03-mount-files.md) Step-by-step instructions from the tutorial: upload via the Files API, wait for the file to pass review, mount_path starting with /uploads/, real sandbox path /mnt/session/uploads/...; closes with the "common issues" entry for the not-found symptom. 3 "Our customer manually reconciles orders every day and wants an AI that produces a daily report." C (sales recommendation mode) Triage first (hands-on + scheduled deliverable → Managed Agent fit), then a three-part outline: directly landable parts (Deployment cron + file deliverable), parts needing verification (data source access), customer-side prerequisites (sample data, accounts); ends with next-step options (one-page proposal, or a live demo agent). 4 "Create an agent and an environment for me so I can start testing." D1 Follows provision.md: init → validate → plan, shows the plan diff to the user, applies only after explicit confirmation; command flags taken from bl COMMAND --help, never from memory. 5 "Give me a Python example that calls the agent and streams the reply to my frontend." D2 Uses existing IDs or environment placeholders and hands over the API/SDK SSE implementation from integration/code-python.md; a live curl smoke test is optional and requires authorization.
Edge Cases
Capability not yet archived (parts marked [TODO] in reference files): say plainly "I don't have this on file yet; I can look it up / you may need to supply it" — never fabricate product facts.
Mixed intents (very common: what is it → then a solution → then provisioning): advance in A → C → D order, one explicit next-step option per step.
Cookbook conflicts with a tutorial or the whitepaper: resolve using current contracts and dated, matching-region evidence, not file category; report the conflict back so the fact can flow into the fact dictionaries.
Talk-only needs (Q&A, retrieval, multi-turn consulting): honestly recommend the Bailian agent app (Flow Agent 2.5) — a wrong recommendation damages trust more than no recommendation.
GTM link unreadable: the GTM material library requires a DingTalk login; if the Agent has no DingTalk session, hand the link to the salesperson directly.
Hand-off target skill missing: fall back to bl COMMAND --help, or suggest installing the skill / running bl skill init.
Whitepaper says "coming soon" but live docs already exist (e.g. MultiAgent, runtime Resource mounting): verify actual availability and report the documented scope.
Fictional companies inside cookbooks (Yunling Tea / Northstar / Shibei E-commerce / Luming Publishing): replace them with the customer's own business nouns when presenting; never cite them as customer cases.
General principles (apply to all four paths)
Never fabricate product facts. Product capabilities, field names, quotas, billing, and availability may only come from content archived under references/product/ and references/integration/ (conclusions in references/tutorials/ and references/cookbook/ that carry a field-test date are equally trustworthy), or from actual output of bl COMMAND --help and the live API docs. Explicit user-provided product corrections may be recorded with their date and provenance (see status); launch confirmation alone does not establish API schemas or account-specific availability. Parts marked [TODO] are not yet archived — do not invent them.
Separate product facts from solution advice. Cite source files when explaining capabilities; when designing solutions, state that this is advice based on product capabilities that needs customer-side confirmation.
Always preview before changing remote resources. Any apply / destroy must first run plan and show the user the diff; only add --yes after the user confirms. Reuse an existing explicit confirmation for the same unchanged plan; ask again only if its scope or state has changed. Details live in the skill bailian-managed-agent.
Make outputs reusable. Deliverables for customers — solutions, tutorial adaptations, integration code — should land as files (agents.yaml, code files, solution markdown), not just chat output.
Path A: explain the product
Goal: within 3 minutes the user knows what problem Managed Agent solves, which resources compose it, and where its boundaries are.
Read references/product/overview.md (capability panorama; source: the official product whitepaper).
If concepts are unclear, read references/product/concepts.md (definitions and relations of Agent / Environment / Session / Deployment / Memory / Vault / Skill / Tool).
For selection, comparisons, and common objections read references/product/faq.md.
Presentation style: lead with how the user's scenario gets solved, then introduce product concepts. Avoid listing the resource model up front.
Close with a next step: "Want to see a tutorial for a similar scenario?" or "Want me to spin up an agent for a trial run?"
Path B: get the user productive
First pick one of two sets (different responsibilities, do not blend):
When the user asks Which set
How to configure a single feature, perform one action, or resolve an error ("how to mount a file" / "how to configure scheduling" / "how to handle requires_action") references/tutorials/index.md — by feature; one capability per tutorial, each with a common-issues table
How a business scenario lands end to end, or wants a complete copyable example, or "what's still missing for production" ("build a morning-report bot" / "notify me when a run finishes" / "several roles collaborating on a proposal") references/cookbook/index.md — by scenario; one playbook chains several capabilities through a full pipeline, REST/curl field-tested
If unsure, start with the smallest useful example matching the request and state its scope; do not block the answer on choosing a tutorial category.
For tutorials: match the user's request against the capability → tutorial mapping table by action verb.
For cookbooks: match against the scenario → playbook mapping table by business need; the company names inside playbooks are fictional — replace them with the customer's own business nouns when presenting.
Once matched, walk the user through the steps, giving directly executable commands / directly saveable configuration at each key step.
When multiple capabilities must combine (e.g. knowledge retrieval + scheduled runs + tool calls): first check whether an existing playbook covers it; if not, assemble per the "combination patterns" in references/tutorials/index.md, stating dependency order and pitfalls.
When the two sets conflict, prefer current official contracts and the most recent relevant field evidence, stating version and region; consult the integration fact dictionary and feature tutorial before copying older cookbook snippets.
Neither matches → do not force-fit. State current coverage, design minimal viable steps on the spot using product capabilities (path A) + CLI capabilities (path D), and suggest adding the new scenario as a tutorial or playbook.
Path C: map product capabilities onto customer problems
Sales recommendation mode (enter here when the inquirer is a salesperson)
This skill typically lives on a salesperson's local Agent: sales ask whenever they hit a customer question or scenario, and this skill supplies the recommendation ammunition. When the inquirer is a salesperson, first follow the three principles below, then move into the methodology.
Triage before recommending. Use the rule "talking and asking picks 2.5; hands-on work or file deliverables picks CMA" to judge the essence of the customer's need: talk-type needs (Q&A, retrieval, multi-turn consulting) honestly fit the Bailian agent app better — do not shoehorn every need into Managed Agent; a wrong recommendation damages trust more than no recommendation. Hands-on needs (run commands, produce files, run on schedule, integrate with business systems) are Managed Agent's home turf.
Recommendations must be verifiable. Every capability pitch given to sales cites only archived content: the capability panorama in references/product/overview.md, objection handling in references/product/faq.md, field-tested conclusions in references/tutorials/, and playbooks from references/cookbook/ as demo-script structural references (company names are fictional and must not be cited as customer cases). If the customer asks about a capability not in the library, reply "I'll go verify this" and do not improvise — every sentence sales takes to a customer is a business commitment.
End with next-step options, not with the recommendation. Immediately after recommending, offer executable options: "Want a one-page solution?" (continue with the methodology below to produce the three-part solution); "Want me to build a live demo agent for the customer?" (go to path D1 — a cookbook playbook can yield a demonstrable pipeline the same day).
Sales do not write code: agents.yaml, APIs, and event streams are prepared by the skill in the background; the deliverables handed to sales are solution highlights + demo arrangements + a list of questions awaiting customer confirmation.
Latest GTM material entry point (when sales needs pitch scripts, product introductions, customer cases, or competitive comparisons for external use): GTM material library — the officially maintained GTM library (DingTalk doc, requires a DingTalk login); it updates faster than this library: for external materials (pitches / introductions / cases) prefer fetching the latest from that link; content archived here may lag. On conflict: marketing wording defers to that link; product-technical facts (fields, endpoints, quotas, availability) still defer to this library and the official docs. If the Agent has no DingTalk login and cannot read the contents, hand the link directly to the salesperson.
Solution design methodology (after sales finish recommending, or when the inquirer is a pre-sales / solution engineer)
Follow the methodology in references/workflows/solution-design.md: use the customer's supplied input sources, decision points, deliverables, system boundaries, and compliance requirements; draft with explicit assumptions when only a proposal is requested, and ask for missing facts that block real execution; then map them onto product capabilities and resource combinations (Agent / Environment / Deployment / mounts / approvals). There is no real customer case library today — for "how do peers do it" questions, design on the spot from product capabilities and say so; the scenario playbooks in references/cookbook/index.md work as structural references (which capabilities a complete pipeline needs, in what order), but their companies are fictional and must not be cited as customer cases.
When outputting a solution, state three parts explicitly: what lands directly / what needs verification / what prerequisites the customer must provide (data, accounts, system interfaces).
Once the customer agrees, move straight into path D to produce agents.yaml and PoC code.
Path D: provision resources + write integration code
Provision resources (create Agent, environment, Deployment, etc.): prefer CLI when supported; apply the update/API fallback above if necessary. For CLI IaC follow references/workflows/provision.md through the init → validate → plan → (user confirmation) → apply chain; command details and flags defer to the skill bailian-managed-agent's reference/managed-agent.md and bl COMMAND --help — never assemble flags from memory.
Write integration code: walk the user through references/tutorials/02-integrate-to-your-system.md first (get remote IDs → curl-verify the chain → pick the pattern → swap in code → production self-check) — use only the steps relevant to the requested deliverable; this is not a requirement to install CLI or create resources; for language implementations go directly to references/integration/code-python.md or references/integration/code-java.md. The full endpoint table and request bodies live in references/integration/api-endpoints.md, auth and event contracts in references/integration/api-quickstart.md, pattern selection in references/integration/patterns.md. When a field is in doubt, pull the official doc page (append .md to the URL for the raw text) to verify.
Order of landing: for a demo, provision with CLI then test one session. For customer integration, go directly to API/SDK using existing IDs or configurable placeholders. Generate code-only deliverables without installing CLI or creating live resources; perform live smoke tests only when requested and credentials are available.
Secrets involved: non-sensitive configuration goes through session environment variables environment_variables (plaintext passthrough into the sandbox); high-sensitivity secrets go into the Vault (the sandbox only sees placeholders; real values are substituted by the egress gateway per the allowed_hosts allowlist) — the selection trade-offs are in references/cookbook/08-vault-secret-injection-and-egress-gateway.md. Either way, never write an API key into code or agents.yaml.
Soft hand-offs (by skill name; if installed, read its SKILL.md; otherwise use --help or suggest bl skill init)
bl managed-agent commands and agents.yaml IaC execution details → skill bailian-managed-agent
Calling already-launched Bailian apps / agents, knowledge bases, usage quotas → skill bailian-cli
Which model to reference inside an Agent → skill bailian-model-recommend
Bailian platform API parameters, error codes, model spec docs → skill bailian-docs-llm-wiki
Image / video / speech generation → skill bailian-gen; model fine-tuning → skill bailian-finetune
Shared protocols: consent confirmation, version pre-checks, auth, error reporting → skill bailian-protocol
Directory map
references/product/ Product knowledge layer: overview (capability panorama) / concepts / faq (selection and objections) / whitepaper-source (archived whitepaper)
references/tutorials/ Feature tutorial layer: index (capability → tutorial mapping + combination patterns) / tutorial files (by action verb, one capability per file)
references/cookbook/ Scenario playbook layer: index (scenario → playbook mapping + capability reverse lookup) / playbook files (by business scenario, REST/curl end-to-end field-tested)
references/workflows/ Operational methodology: provision (resource provisioning chain) / solution-design (requirements → solution)
references/integration/ Integration layer: api-quickstart (entry / auth / minimal loop / event contract) / api-endpoints (full endpoint table) / patterns (integration shapes)
code-python, code-java (runnable implementations of the three shapes)
references/product/ + references/integration/ are the fact dictionaries (the single source of truth for fields, endpoints, quotas, error codes); references/tutorials/ + references/cookbook/ are usage; new facts discovered while running playbooks flow one-way back into the fact dictionaries — never let the two sides tell different stories.
阿里云 Lakehouse 迁移调度器
旅行清单与行前准备