跳到正文
观猹观猹学社

从 CLI 能力入口，到企业级 Agent 生产系统

用 CLI、Skill 与 Agent 打通企业系统，再通过权限、状态、评测和人工兜底把工作流带进生产环境。

✦全文约 5400 字 阅读需 18 分钟 若琪 最近更新 2026.08

01课程介绍#

本节课围绕企业内部系统接入展开。你会比较 API、MCP 与 CLI 的能力边界，并理解 Agent 如何连接 CRM、知识库、数据库和工单系统。

连通只是第一步。真正的企业交付还需要处理身份、权限、状态、审计、安全、失败恢复与人工兜底，才能让一次演示变成可持续运行的业务流程。

你将学到什么

  • 比较 API、MCP 与 CLI 的适用场景和选型依据。
  • 把业务动作翻译成 Agent 可以调用和验证的能力。
  • 设计身份认证、权限控制、审计与数据安全边界。
  • 搭建一条可解释、可恢复、可验收的企业 Agent 链路。

02课程回放#

正在准备课程回放…
本节课的核心判断 企业真正需要的不是一个偶尔跑通的 Agent，而是一条 能力可调用、业务可解释、过程可恢复、结果可验收、风险可控制 的生产链路。CLI 解决能力入口，企业级 Runtime 与治理体系解决持续交付。

03课程课件#

完整课件正在载入…

04为什么 Agent 需要 CLI#

传统软件围绕人设计：用户看页面、理解菜单、点击按钮，再从视觉反馈中判断结果。Agent 不需要这套图形交互，它更需要一个结构清晰、参数明确、返回稳定、错误可处理的能力入口。

CLI（Command Line Interface，命令行界面）正好提供了这样的入口。Agent 可以通过帮助命令发现能力，用参数表达意图，以退出码和结构化结果判断成功或失败，再把多个命令组合成完整任务。

可发现通过命令名称与 --help 理解有哪些能力、参数怎样填写。
可调用不依赖视觉识别和鼠标操作，直接执行模型、应用或平台命令。
可解析返回结构化数据、稳定错误码和清晰日志，方便 Agent 继续判断。
可组合与 Skill、脚本、本地工具和其他 CLI 串联，形成跨能力工作流。
可审计命令、参数、执行人、时间和结果可以进入日志与权限体系。
UI 自动化适合作为补充，不宜成为默认入口 Computer Use 可以操作只有界面的遗留系统，但视觉理解、页面变化和多轮操作会增加耗时、Token 与失败概率。能通过 API 或 CLI 暴露的能力，应优先使用结构化接口。

API、MCP 与 CLI 如何分工

三者不是互斥关系。API 是底层系统能力的程序接口；MCP 为 Agent 提供标准化工具发现和调用协议；CLI 是可以独立使用、组合和测试的命令行产品，背后可以调用 API，也可以桥接其他工具。

方式 更适合的场景 主要注意点
API 系统间稳定集成、服务端高并发调用、明确的数据读写 需要自行处理认证、编排、错误与客户端封装
MCP 让 Agent 标准化发现并调用一组工具或数据资源 工具过多会占用上下文，也会增加选错工具的概率
CLI 本地 Agent、开发运维、批处理，以及多个能力的组合 要设计帮助、结构化输出、退出码、版本和认证体验
UI 自动化 无 API、无法二开的遗留网页或桌面软件 容易受页面变化影响，应增加截图、校验与人工兜底

05百炼 CLI：把模型与平台能力交给 Agent#

百炼 CLI 的目标，是把阿里云百炼中的多模态模型、应用与平台管控能力转化为 Agent 能直接发现和调用的原子命令。用户可以继续使用 Codex、Qwen Code、Claude Code 等熟悉的 Agent，只需通过 CLI 接入所需能力。

一条完整的能力链 用户需求 → Coding Agent → 百炼 CLI → 模型与平台能力 → 专家 Skill 编排 → 图片、视频、音频、文档或应用结果。

课程开场展示的两分钟短剧，并不是某个视频模型一次生成的。Agent 需要先理解创作意图，再借助影视 Skill 拆解场景和镜头，为每个镜头生成提示词，分别调用图像、视频和语音能力，最后用本地工具合成并检查成片。

  1. 理解需求把“日系校园、青涩初恋、两分钟”等模糊描述变成明确创作约束。
  2. 规划内容由影视专家 Skill 设计故事节奏、场景、角色与镜头顺序。
  3. 生成分镜逐镜编写提示词，控制人物、画面和叙事连贯性。
  4. 调用多模态模型分别完成图像、视频、对白与声音生成。
  5. 本地合成与校验通过 Remotion、FFmpeg 等工具拼接素材、处理字幕并检查交付物。

产品宣传片和个人数字人口播案例也遵循相同模式：CLI 提供原子能力，Skill 提供专业流程，Agent 负责根据当前任务做规划与编排。真正形成业务结果的不是单个模型，而是模型、工具、知识和流程的组合。

从本地工作流到云端应用

百炼 CLI 给出了三阶段的能力路径。先解决自己的问题，再把验证过的能力交给更多人，最后结合平台能力继续提高效果和治理水平。

  1. 本地 Agent + CLI + Skill 在自己的开发环境中快速试验，用一句需求调用模型和工具，跑通最短工作流。
  2. Managed Agent 将本地已经验证的 Skill 与工作流发布为云端 Agent，供团队、客户或二次产品使用。
  3. 模型与平台深化 接入模型调优、知识库、记忆、MCP、用量查询与其他平台管控能力，形成更完整的场景方案。

Agent Studio 则把已经配置好的云端 Agent 与专家能力做成在线体验入口。对不熟悉本地环境和 CLI 的用户来说，可以直接选择场景并输入需求；需要高度定制时，再回到本地 Agent 与 Skill 进行开发。

06如何把一个软件系统改造成 Agent 可操作能力#

如果企业系统已有稳定 API，CLI 通常只需要做一层清晰的命令路由，不必重写原系统。若采购软件无法二开，则要判断它是否提供开放接口、数据库访问、导入导出或自动化能力；全部缺失时，才考虑浏览器或桌面自动化桥接。

  1. 先选一条真实任务不要一开始暴露整个系统，先确定 Agent 要完成的一次读取或写入。
  2. 盘点可用接口优先复用后端 API，其次使用官方扩展与数据接口，最后才是 UI 自动化。
  3. 设计命令边界按用户任务命名命令，参数明确，查询与变更操作分离。
  4. 提供机器可读结果支持 JSON 等结构化输出，并设置稳定退出码和可行动的错误信息。
  5. 补齐身份与权限复用企业身份，遵守最小权限，避免把高风险管理员能力默认交给 Agent。
  6. 处理生产可靠性为写操作增加幂等键、超时、重试、确认、审计和回滚策略。
  7. 再用 Skill 封装经验告诉 Agent 何时使用、先后步骤、业务规则和需要人工确认的边界。
# 示例：查询报销单
expense claims list --status pending --output json

# 示例：查看单据详情
expense claims get --id CLM-20260730-001 --output json

# 示例：高风险写操作先预览，再显式提交
expense claims approve --id CLM-20260730-001 --dry-run
expense claims approve --id CLM-20260730-001 --confirm
“能调用”不是“可以无条件执行” 查询、预览和草稿可以提高自动化程度；审批、删除、付款、对外发布等重要操作必须结合身份权限、影响预览、人工确认与审计记录。技术入口不能绕过企业治理。

07企业级 Agent 的难点不止是接入#

个人 Agent 偶尔失败，用户通常可以重试或手工修改；企业 Agent 一旦进入客服、财务、库存、审核等生产流程，就必须在大量请求、长时间运行和多人协作中保持稳定。企业要的是持续可用的业务结果，而不是一次惊艳演示。

课程给出的生产判断是：进入真实试运行前，应以较高准确率作为门槛，并为剩余风险设置人工兜底。具体阈值必须由业务风险决定，不能只看一次 Demo 或单个节点的表现。

影响因素 常见问题 对应措施
业务上下文 专家脑中的隐性规则和例外没有被说清 业务翻译、样例访谈、流程与异常清单
知识质量 政策、商品或内部规则更新后知识库未同步 知识责任人、版本、时效和变更流程
Skill 与工具 能力重叠、描述模糊，Agent 选择错误 任务隔离、精简工具集、离线评测与排序
模型执行 同一目标多次执行存在判断漂移 结构化目标、明确规则、交叉验证和强模型
长链路状态 模型、网络或系统任一步失败导致整条任务中断 检查点、幂等、重试、断点续跑和补偿
组织协作 业务、技术与运维对责任和结果理解不同 明确负责人、审批点、SLA 和验收指标
单步成功率看起来很高，也不代表长链路可靠。假设十个相互独立的步骤都只有 95% 成功率，整条链路一次走完的理论成功率约为 60%。生产系统必须在关键节点校验、恢复和兜底。

08先把业务翻译成 Agent 能执行的结构#

DeskClaw 企业版把业务翻译作为 Agent 开发的起点。业务专家先提供流程说明、规则、培训材料、模板和真实样例，平台再把它们抽取成可确认的业务工作流。技术团队不应在业务尚未说清时直接堆节点或写代码。

完整任务可以抽象为一个 Job，其中每个相对独立的动作是一个 Task。每个 Task 至少要确认四类信息：

Input输入来自哪里、包含哪些字段、数据质量和权限条件是什么。
Process处理逻辑、判断规则、先后顺序，以及要调用的知识和工具。
Output输出结构、使用对象、质量标准，以及如何进入下一步。
Exception缺数据、规则冲突、工具失败或低置信度时怎样处理、由谁确认。

这种拆解不是为了把业务画得更复杂，而是让每个阶段都能独立验证，并隔离当前任务不需要的知识、Skill 与工具。把几十个能力一次交给同一个 Agent，通常会降低选择稳定性，也让后续问题难以定位。

哪些任务更值得优先改造

课程给出了两个实用筛选方向：一是人力密集，重复任务多、并发高；二是知识密集，专家培养慢、判断经验稀缺。两者同时满足的场景，通常更容易形成明确业务价值。

  1. 流程执行 财务报销、订单处理、运营任务等步骤较固定的流程。
  2. 审核校验 供应商入库、商品上架、资质与材料合规检查。
  3. 专业问答 设备维修、内部制度、产品与行业知识服务。
  4. 分析与决策 根因分析、经营诊断、策略建议和决策辅助。

无论选择哪类任务，都要回答：服务哪个团队和角色、当前问题是什么、谁对结果负责、怎样量化价值，以及方案能否在相邻团队或场景中复用。

09企业级 Agent 的六步落地链路#

  1. 选准任务 从频率、成本、风险、专家稀缺度与复用空间判断优先级，不从“想做一个 Agent”出发。
  2. 说清任务 由业务专家与 FDE 共同确认目标、输入输出、规则、知识、系统、角色和异常。
  3. 装配能力 技术团队为每个 Task 配置模型、知识库、Skill、API、CLI、人工审核点和上下文策略。
  4. 稳定执行 Runtime 负责有状态调度、并发、超时、检查点、重试、断点续跑和异常恢复。
  5. 治理与量化 记录权限、成本、耗时、异常、人工介入和业务结果，让运维与管理者看到真实价值。
  6. 沉淀模板 把已经验证的流程、知识结构、Skill 与评测集复用到相邻部门和客户，而不是重新开发。

Runtime 解决什么问题

企业任务可能持续数小时甚至数天，中间要等待审批、外部数据或人工确认。Runtime 不能让一个进程一直挂起，而要保存状态，在事件到来后从正确节点继续。

状态快照保存当前节点、输入、输出、工具结果和待处理事项。
断点续跑系统重启、网络失败或人工等待结束后，从最近安全节点恢复。
幂等与重试重复执行不会产生重复订单、重复审批或重复扣款。
循环与超时检测识别无效反复、模型超时和工具异常，及时终止或转人工。
全链路 Trace还原每一步使用的输入、模型、知识、工具、结果与决策。
告警与人工队列把低置信度、高风险和无法自动恢复的任务交给明确负责人。

10从离线评测到 AI First#

企业 Agent 不应开发完成后直接接管生产。课程以智能客服为例，给出了一条逐步扩大自动化范围的上线方式。

  1. 离线评测 使用历史真实问题与业务样本运行 Agent，由领域专家抽样打分，验证准确率与主要失败类型。
  2. 影子系统 人继续正常工作，Agent 在后台处理同一任务；比较两者差异，但不影响真实用户。
  3. 辅助模式 Agent 先给出结果或建议，由人确认、修改或拒绝，同时统计采纳率和修改原因。
  4. AI First 仅对高置信度、低风险场景自动执行；退款、高价值客户、敏感内容等继续转人工。
  5. 持续运营 监控准确率、满意度、转化、异常率、人工介入率和成本，把新 Bad Case 加入评测集。

这里的关键不是只用另一个大模型自检。模型评审可以降低人工筛选成本，但业务正确性仍要通过真实规则、历史结果、专家抽样和线上指标共同确认。

智能客服不应只是“会查知识库”

消费者排斥的往往不是 AI 身份本身，而是回答只复述参数，没有理解购买场景，也没有解释产品价值。比如用户询问成分，机械返回成分表虽然事实正确，却没有回答“它对我的肤质有什么意义”。

更好的客服 Agent 需要理解产品、用户、上下文和服务目标：常规事实可以自动回答；涉及推荐时说明依据；信息不足时主动追问；退款、投诉和高价值客户则及时交给真人。温度最终要落实为更完整的上下文和更合理的服务策略。

11从一次交付到企业 Agent 资产#

当业务流程、Task、知识、Skill、工具、评测和运行数据都被结构化后，一次项目就不再只是定制开发。相邻团队可以复制模板，替换自己的规则、知识和连接器，快速形成新 Agent。

沉淀层 可复用资产 带来的价值
业务层 Job / Task 模板、规则、异常处理与验收口径 相邻团队不必从空白需求重新访谈
能力层 知识结构、Skill、CLI、API 连接器与工具 通用能力可以被多个任务共同调用
运行层 状态、重试、审批、权限、Trace 与告警机制 不同 Agent 共用稳定的生产底座
评测层 正常样本、边界样本、Bad Case 与评分规则 版本迭代有基线，问题不会反复出现
经营层 耗时、Token、成功率、人工介入与业务结果 管理者能够判断投入产出与扩展优先级

这也是 FDE 在企业现场的重要职责：不仅完成系统接入，还要让业务专家、技术团队、运维人员和最终使用者在同一条链路上协作，并把现场经验沉淀成下一次可以直接复用的产品能力。