1. 项目概述：为什么企业需要OpenClaw？

如果你正在寻找一个能打通企业内部各种应用、让AI真正帮你干活的自动化工具，那么OpenClaw这个名字最近一定频繁出现在你的视野里。它不是一个简单的聊天机器人，而是一个开源的、可编程的AI智能体（Agent）框架，核心目标是把大语言模型（LLM）的能力，像“爪子”一样，精准地嵌入到你日常工作的每一个流程中。简单来说，它能让你的AI助手不仅会聊天，还能替你操作软件、处理数据、执行任务，从“参谋”变成“实干家”。

我接触OpenClaw，是因为团队内部长期被跨系统、重复性的手动操作困扰。比如，销售线索从官网表单到CRM系统，再到分配提醒，中间全靠人工复制粘贴；又比如，每天需要从十几个不同的数据源抓取报表，手动整合成一份简报。这些工作枯燥、易错，还占用大量人力。市面上的SaaS自动化工具要么太贵，要么不够灵活，无法深度定制。OpenClaw的出现，让我们看到了用开源方案实现深度业务流程自动化的可能性。

它适合谁？首先是中小型企业的技术负责人或开发者，希望以较低成本构建定制化AI工作流；其次是业务部门的“自动化先锋”，懂业务逻辑，愿意用技术提效；最后是任何对AI应用开发感兴趣的极客。OpenClaw的学习曲线存在，但它的回报是：你将获得一个完全可控、能随业务成长、且深度集成的AI自动化中枢。

2. 核心架构与设计思路拆解

要玩转OpenClaw，不能只停留在“安装启动”，必须理解其核心设计哲学。它不是一个单体应用，而是一个以“智能体”为中心的协同生态系统。

2.1 核心组件：Skill, Gateway与MCP

OpenClaw的架构清晰地区分了“能力”、“通道”和“工具”。

Skill（技能） ：这是OpenClaw的“肌肉”，是具体执行某个任务的能力单元。例如，一个“发送邮件”Skill、一个“查询数据库”Skill、一个“生成周报”Skill。每个Skill都是一个独立的、可插拔的模块。OpenClaw社区提供了大量预置Skill，你也可以用Python轻松开发自己的Skill。关键在于，Skill的设计应该是原子化的、功能单一的，这样便于复用和组合。

Gateway（网关） ：这是OpenClaw的“感官”和“嘴巴”，负责与外部世界通信。用户通过Gateway与OpenClaw交互。最常见的Gateway包括：

  • WebUI Gateway ：提供一个网页聊天界面，用于测试和内部轻量级使用。
  • 企业微信/飞书/DingTalk Gateway ：将OpenClaw接入企业内部办公平台，员工直接在熟悉的聊天窗口里就能调用AI助手完成任务。
  • API Gateway ：开放HTTP API，供其他业务系统调用，实现系统间的自动化触发。

MCP（Model Context Protocol）配置 ：这是OpenClaw的“大脑”连接器。MCP是一种新兴协议，用于标准化LLM与外部工具/数据源的交互。在OpenClaw中，MCP配置至关重要，它决定了你的智能体可以调用哪些工具（比如搜索引擎、代码解释器、内部API）。通过配置MCP服务器，你可以安全、可控地将内部工具暴露给AI使用，而无需将敏感信息直接写入Prompt。

2.2 工作流引擎：从线性任务到动态编排

OpenClaw的核心魅力在于其工作流引擎。它不仅仅是“接收指令-调用Skill-返回结果”的简单循环。

基于LLM的意图识别与路由 ：用户输入一句自然语言，如“帮我把昨天销售数据整理成图表发到群里”。OpenClaw会首先利用LLM理解这句话的意图，拆解出关键动作（查询数据、生成图表、发送消息）和参数（时间：昨天，数据：销售，目标：群聊）。这个过程不再是简单的关键词匹配，而是真正的语义理解。

动态技能编排（Orchestration） ：识别意图后，OpenClaw的工作流引擎会根据技能库和能力描述，动态规划出一个执行序列。它可能会先调用“数据库查询”Skill获取数据，然后将结果传递给“数据可视化”Skill生成图表，最后调用“企业微信消息”Skill将图表发送到指定群组。这个编排过程可以是并行的，也支持条件判断和循环。

状态管理与错误处理 ：一个复杂的工作流可能包含多个步骤。OpenClaw需要维护整个工作流的执行状态，记录中间结果。当某个Skill执行失败时（例如，数据库连接超时），引擎不能直接崩溃，而应该根据预设的策略进行重试、降级处理（如使用缓存数据）或通知人工介入。一个健壮的OpenClaw应用，其错误处理逻辑的设计往往比主流程更费心思。

3. 30个典型企业应用场景深度解析

选择场景不能拍脑袋，必须结合业务痛点和技术可行性。下面我将30个场景分为四大类，并挑选几个最具代表性的进行深度拆解。

3.1 办公与协作增效类

这类场景直接提升员工日常工作效率，见效快，接受度高。

场景1：智能会议助手

  • 痛点 ：会议纪要整理耗时耗力，会后行动项跟踪容易遗漏。
  • OpenClaw实现 ：
    1. 通过飞书/腾讯会议Gateway，让OpenClaw接入会议。
    2. 在会议开始时，@OpenClaw并发送指令“开始记录本次会议”。
    3. OpenClaw利用语音转文本Skill（可集成第三方ASR服务）实时转录。
    4. 会议结束后，发送“生成纪要”，OpenClaw调用LLM Skill，总结会议要点、待办事项（TODO），并自动识别负责人。
    5. 最后，调用“任务创建”Skill，将待办事项同步到团队的Jira、Teambition或飞书任务中心。
  • 实操心得 ：语音识别的准确性是关键，建议在正式使用前，用内部会议录音进行模型微调或选择适合中文商业场景的ASR服务。对于行动项的识别，可以在Prompt中明确公司常用的人名和项目名，提高识别准确率。

场景2：跨平台信息聚合与推送

  • 痛点 ：管理者需要每天关注多个数据看板、舆情监控、竞品动态等信息源。
  • OpenClaw实现 ：
    1. 开发或使用现成的“网页抓取”、“API查询”Skill。
    2. 配置一个定时触发的工作流（Cron Job）。
    3. 工作流依次从指定数据源（如公司BI系统、Google Analytics、社交媒体监听平台）拉取数据。
    4. 调用LLM Skill对数据进行摘要分析，提炼关键指标和异常波动。
    5. 在每天上午9点，通过企业微信Gateway，将格式化后的每日简报推送给指定管理者。
  • 注意事项 ：注意数据抓取的频率和对方服务器的限制，避免被封IP。对于重要数据，建议实现缓存机制，当数据源不可用时能提供最近一次的有效数据。

3.2 客户服务与营销自动化类

这类场景直接面向客户，对稳定性和准确性要求极高。

场景3：电商客服智能辅助

  • 痛点 ：80%的客服咨询是重复性问题（物流、退货、优惠），占用大量人力。
  • OpenClaw实现 ：
    1. 通过API Gateway，将OpenClaw与电商客服系统（如智齿、美洽）或企业微信客服对接。
    2. 当客户接入时，OpenClaw实时分析客户问题。
    3. 对于标准问题（如“我的订单到哪了”），直接调用“订单查询”Skill，从数据库获取物流信息并回复。
    4. 对于复杂问题，OpenClaw可以为人工客服生成推荐回复话术，或自动从知识库中检索相关文档，供客服参考。
    5. 对话结束后，自动调用“客户反馈分类”Skill，为对话打标签，沉淀到CRM。
  • 深度解析 ：这里的关键是“智能辅助”而非“完全替代”。OpenClaw应定位为客服的“超级副驾”，处理琐事、提供信息，将复杂、情绪化的交流留给人。需要建立完善的“移交”机制，当AI置信度低或客户要求转人工时，无缝切换。

场景4：个性化营销内容生成

  • 痛点 ：市场部需要为不同渠道、不同客户群体生成海量的文案、海报描述、邮件主题等，创意枯竭，效率低下。
  • OpenClaw实现 ：
    1. 在OpenClaw中配置针对不同渠道（公众号、小红书、EDM）和产品线的内容模板Skill。
    2. 市场人员输入核心卖点和目标人群，如“为一款新的降噪耳机生成5条小红书风格的种草文案，目标用户是通勤白领”。
    3. OpenClaw调用LLM Skill，结合模板和产品知识库，批量生成多种风格的文案供选择。
    4. 选定文案后，可进一步触发工作流，调用“设计工具API”Skill（如Canva）生成配图初稿。
  • 避坑指南 ：必须为AI生成的内容设置人工审核环节。可以在工作流中内置一个“审批节点”，生成的内容先发送到企业微信的审批群，由负责人确认后再发布。同时，要持续用优秀的人工创作样本“喂养”和微调你的内容生成Skill，使其风格更贴近品牌调性。

3.3 研发与运维提效类

技术团队是OpenClaw的天然重度用户，能用它自动化大量繁琐操作。

场景5：智能运维告警与自愈

  • 痛点 ：半夜收到服务器CPU告警，需要登录机器、查看进程、分析日志、决定重启还是扩容，流程漫长。
  • OpenClaw实现 ：
    1. 将Zabbix、Prometheus等监控系统的告警Webhook指向OpenClaw的API Gateway。
    2. 配置告警处理工作流。收到告警后，OpenClaw首先调用“服务器诊断”Skill（通过SSH执行一系列预置命令），获取详细状态。
    3. 将告警信息和诊断结果发送给LLM Skill进行分析。LLM根据历史工单和知识库，判断这是一个常见问题（如某个服务内存泄漏）还是新问题。
    4. 对于已知问题，直接执行“自愈”Skill（如重启特定服务、清理缓存）。
    5. 对于新问题或自愈失败，立即创建工单并@相关运维人员，同时将初步分析报告附上。
  • 核心技巧 ：自愈动作一定要谨慎！务必在Skill中设置“安全边界”，例如，只允许在特定时间段（如工作时间）对非核心服务进行重启操作。对于数据库、支付网关等关键服务，自愈流程必须加入人工确认环节或更复杂的回滚机制。

场景6：代码审查辅助与知识问答

  • 痛点 ：新人提交的代码可能存在常见坏味道，但资深工程师没时间逐一详细评审；团队内部技术问题重复解答。
  • OpenClaw实现 ：
    1. 通过GitLab/GitHub的Webhook，将代码推送事件通知OpenClaw。
    2. OpenClaw调用“代码分析”Skill，使用静态分析工具（如SonarQube）或直接让LLM扫描代码，找出潜在问题（如安全漏洞、性能问题、不规范的写法）。
    3. 将分析结果以评论形式自动提交到代码合并请求（MR）中。
    4. 同时，可以搭建一个内部技术知识库，员工在企业微信中直接向OpenClaw提问：“K8s中如何优雅滚动更新？” OpenClaw检索知识库和官方文档，生成结合公司实践的答案。
  • 经验分享 ：代码审查的AI评论要注重“建议性”而非“指责性”。Prompt要设计成“这里发现了XX模式，可能会引起YY问题，建议参考团队规范ZZZ”。对于知识问答，答案后一定要附上来源链接，方便用户追溯和验证。

3.4 数据流程自动化类

这是OpenClaw最能体现“胶水”价值的领域，连接各个数据孤岛。

场景7：跨系统数据同步与清洗

  • 痛点 ：市场部的线索在MKT系统，销售在用CRM，财务数据在ERP，数据不同步，手工导出导入易出错。
  • OpenClaw实现 ：
    1. 为每个源系统和目标系统开发对应的“连接器”Skill（通常就是调用其API）。
    2. 配置定时或事件触发的工作流。例如，当MKT系统有新线索符合条件（如评分>80），触发工作流。
    3. 工作流读取该线索详细信息，按照CRM要求的格式进行映射和转换（如字段名转换、值清洗）。
    4. 调用CRM Skill创建或更新客户/联系人记录。
    5. 同步完成后，向企业微信群发送通知。
  • 参数与配置详解 ：数据映射规则是核心。建议将这些规则配置化，存储在一个独立的配置文件或数据库中，而不是硬编码在Skill里。这样当CRM字段变更时，只需更新配置，无需修改代码。同时，必须实现“幂等性”处理，即同一数据源多次触发同步，不会在目标系统产生重复记录。

场景8：动态报表生成与分发

  • 痛点 ：每周/每月需要为不同部门制作固定格式的报表，数据来源分散，制作过程机械。
  • OpenClaw实现 ：
    1. 开发“数据抽取”Skill群，分别从数据库、数据仓库、第三方SaaS获取原始数据。
    2. 使用“数据处理”Skill（如调用Pandas库）进行聚合、计算。
    3. 将处理后的数据传递给“报表生成”Skill，该Skill可以使用Jinja2模板引擎，将数据填充到预定义的HTML/Excel模板中。
    4. 生成报表文件后，通过“邮件”或“企业微信文件”Skill，分发给预设的收件人列表。
  • 高级技巧 ：可以引入简单的参数化。例如，部门主管在群里说“给我看一下上季度A产品的销售报表”，OpenClaw能解析出“时间：上季度”、“产品：A”，动态调整数据查询和报表标题，实现交互式报表生成。

4. 从零到一的部署与核心配置实战

理解了场景，我们进入实战。部署OpenClaw有多种方式，这里以最主流、最易管理的 Docker Compose 部署为例，并详解关键配置。

4.1 基础环境部署

假设我们在一台Ubuntu服务器上进行部署。

# 1. 安装Docker和Docker Compose
sudo apt-get update
sudo apt-get install docker.io docker-compose -y

# 2. 创建项目目录并下载docker-compose.yml
mkdir openclaw-enterprise && cd openclaw-enterprise
curl -O https://raw.githubusercontent.com/openclaw/openclaw/main/docker-compose.yml

下载的 docker-compose.yml 文件定义了多个服务：核心的 openclaw 服务、数据库（如PostgreSQL）、Redis缓存等。在启动前， 必须 修改环境变量配置文件（通常是 .env 文件或 docker-compose.yml 中的 environment 部分）。

关键配置解析：

  • OPENCLAW_MODEL ：指定默认使用的大模型。对于企业内网环境，强烈建议使用本地部署的模型，如通过Ollama部署的 qwen:7b 、 llama2:7b 或 deepseek-coder:6.7b 。配置为 OPENCLAW_MODEL=ollama/qwen:7b 。
  • OLLAMA_BASE_URL ：指向你部署的Ollama服务地址。如果Ollama和OpenClaw部署在同一台机器，且Ollama使用默认端口，则为 OLLAMA_BASE_URL=http://host.docker.internal:11434 。注意，在Docker网络中，需要用 host.docker.internal 指代宿主机。
  • OPENCLAW_DATABASE_URL ：数据库连接字符串，用于持久化技能、工作流配置和会话历史。

注意 ：很多初学者在部署后遇到 openclaw llamap svr operator(): got exception: { "error": { "code": 400, ... 这类错误，90%的原因都是 OLLAMA_BASE_URL 配置错误或Ollama服务中的模型名称与 OPENCLAW_MODEL 不匹配。务必先用 curl http://<ollama-host>:11434/api/tags 确认模型列表。

配置完成后，一键启动：

docker-compose up -d

访问 http://你的服务器IP:3000 即可看到OpenClaw的WebUI。

4.2 核心技能（Skill）安装与配置

启动后，第一件事就是安装Skill。WebUI通常有Skill市场，但企业环境更推荐通过配置文件或命令行管理。

以安装一个“发送邮件”Skill为例：

  1. 查找Skill ：在OpenClaw的官方Skill仓库或社区中寻找可靠的邮件Skill，例如 openclaw-skill-email 。
  2. 安装 ：如果Skill是Python包，可以将其添加到OpenClaw容器的依赖中，或者通过OpenClaw的管理API安装。 
    # 进入openclaw容器
docker exec -it openclaw-enterprise-openclaw-1 /bin/bash
# 假设Skill可以通过pip安装
pip install openclaw-skill-email
  3. 配置 ：安装后，需要在OpenClaw的配置目录（如 /app/config ）或WebUI的管理页面中，配置该Skill所需的参数：SMTP服务器地址、端口、加密方式、发件邮箱账号和密码（或授权码）。
  4. 测试 ：在WebUI中，尝试使用这个Skill。输入指令：“用我的工作邮箱给 test@company.com 发送一封测试邮件，标题‘OpenClaw测试’，内容‘Hello from OpenClaw’”。

企业级Skill管理建议 ：

  • 私有化部署Skill仓库 ：将公司自研的Skill和经过审核的第三方Skill打包，部署到内部的PyPI或Git仓库，确保安全、可控。
  • 配置中心化 ：不要将密码等敏感信息硬编码在Skill代码或容器环境变量里。使用HashiCorp Vault、AWS Secrets Manager或至少是加密的配置文件来管理密钥。
  • 版本控制 ：对Skill的代码和配置进行Git版本控制，方便回滚和协作。

4.3 网关（Gateway）集成：以企业微信为例

让OpenClaw融入现有工作流，网关集成是关键一步。这里详细讲解企业微信自建应用接入。

步骤拆解：

  1. 创建企业微信自建应用 ：

    • 登录企业微信管理后台，进入“应用管理” -> “自建应用”，创建应用，记录下 AgentId 、 Secret 和 CorpId （企业ID）。
    • 配置应用可信IP，填入你部署OpenClaw服务器的公网IP。
    • 配置接收消息的API地址，格式为： http://你的公网域名或IP:端口/wecom/gateway 。这个URL后续要在OpenClaw的企业微信Gateway配置中填写。

  2. 部署并配置OpenClaw企业微信Gateway ：

    • 通常有独立的 openclaw-gateway-wecom 服务。在 docker-compose.yml 中添加该服务定义。
    gateway-wecom:
  image: someorg/openclaw-gateway-wecom:latest
  container_name: openclaw-gateway-wecom
  environment:
    - WECOM_CORP_ID=你的企业CorpId
    - WECOM_AGENT_ID=你的应用AgentId
    - WECOM_AGENT_SECRET=你的应用Secret
    - WECOM_TOKEN=自定义的Token # 用于验证消息，需与企微后台配置一致
    - WECOM_ENCODING_AES_KEY=自定义的EncodingAESKey # 用于消息加解密，需与企微后台配置一致
    - OPENCLAW_API_URL=http://openclaw:3000/api # 指向OpenClaw核心API
  ports:
    - "8080:8080" # 网关服务暴露的端口
  depends_on:
    - openclaw
    • 这里的 OPENCLAW_API_URL 使用了Docker Compose的服务名 openclaw ，这是容器内部的网络通信。

  3. 验证与调试 ：

    • 启动网关服务： docker-compose up -d gateway-wecom 。
    • 在企业微信后台保存应用配置。如果URL和Token验证成功，配置即保存成功。
    • 此时，在企业微信中向该应用发送消息，消息会先到达 gateway-wecom 服务，再转发给 openclaw 核心处理，并将回复传回企业微信。

实操心得 ：企业微信等网关配置中最常见的坑是 网络连通性 和 加密配置 。确保你的服务器8080端口对外开放，且防火墙规则允许。 Token 和 EncodingAESKey 必须与企业微信后台完全一致，包括大小写。建议在网关服务的日志中开启Debug模式，查看消息接收和转发的全过程。

5. 流程优化与高阶实践

部署成功只是第一步，让OpenClaw稳定、高效、安全地运行，需要持续的优化。

5.1 性能优化与高可用设计

单实例优化 ：

  • 模型层 ：使用量化后的模型（如GGUF格式）以减少内存占用和提升推理速度。为Ollama配置GPU加速（如果服务器有GPU）。
  • 缓存策略 ：为频繁查询且变化不频繁的数据（如产品目录、组织架构）设计缓存Skill，利用Redis存储结果，避免重复调用LLM或查询数据库。
  • 异步处理 ：对于耗时长的工作流（如生成一份复杂的季度报告），不要同步阻塞等待。让OpenClaw接收到请求后立即返回“任务已接收”的提示，然后在后台异步执行，执行完毕后再通过消息Gateway通知用户。

高可用架构 ： 对于核心业务场景，单点部署风险太高。可以考虑：

  • 无状态化 ：确保OpenClaw核心服务是无状态的，将会话、技能状态等信息存储在外部数据库（PostgreSQL）和缓存（Redis）中。
  • 多实例部署 ：使用Docker Swarm或Kubernetes部署多个OpenClaw实例，前面通过Nginx或K8s Service做负载均衡。
  • 网关冗余 ：企业微信网关也可以部署多个实例，通过负载均衡器对外暴露一个统一入口。
  • 故障转移 ：监控各个服务健康状态，出现故障时能自动重启或切换到备用实例。

5.2 安全与权限管控

企业应用，安全第一。

  • 网络隔离 ：将OpenClaw及其依赖的服务（数据库、Redis、Ollama）部署在内网，仅通过网关服务（如企业微信网关）暴露必要的端口给外部。禁止将OpenClaw的管理界面（WebUI）直接暴露在公网。
  • 技能权限控制 ：不是所有用户都能调用所有Skill。例如，“服务器重启”Skill只能由运维人员使用。需要在Gateway或OpenClaw核心层实现基于用户/角色的权限校验。可以在接收到用户请求时，先根据用户身份判断其是否有权执行工作流中的特定技能。
  • 数据脱敏与审计 ：对于Skill处理的数据，尤其是调用外部API时，要设计脱敏逻辑。例如，查询客户信息时，身份证号、手机号等敏感字段应在日志和中间结果中被部分屏蔽。同时，所有用户的操作指令、Skill的调用记录、产生的数据结果，都应记录到审计日志中，便于追溯。
  • 模型安全护栏（Safety Guardrail） ：在用户输入传递给LLM之前，以及LLM输出返回给用户之前，可以插入一层“安全检查”Skill。这层Skill用规则或小模型过滤掉明显的恶意指令、敏感话题或不符合公司政策的内容。

5.3 监控、日志与问题排查

“没有监控的系统就是在裸奔。”

  • 监控指标 ：

    • 服务健康 ：各容器/进程的存活状态、CPU/内存使用率。
    • 模型服务 ：Ollama的响应延迟、Token消耗速率。
    • 业务指标 ：各Skill的调用次数、成功率、平均耗时；工作流的执行数量、失败率。
    • 网关指标 ：消息接收/发送速率、消息处理延迟。

  • 日志聚合 ：使用ELK（Elasticsearch, Logstash, Kibana）或Loki+Grafana堆栈，将OpenClaw核心、各个Gateway、Skill的日志集中收集、索引和可视化。为不同级别的日志（DEBUG, INFO, ERROR）设置清晰的输出格式。

  • 问题排查实录 ：

    • 问题 ：用户反馈在企业微信中@机器人无反应。
    • 排查步骤 ：
      1. 检查网关服务 gateway-wecom 容器日志： docker logs -f openclaw-gateway-wecom 。看是否有收到企业微信的消息回调。
      2. 如果网关收到了消息，检查它是否成功转发给了OpenClaw API。查看日志中是否有向 OPENCLAW_API_URL 发起的POST请求及响应状态码。
      3. 如果网关请求失败（如连接超时、500错误），检查OpenClaw核心服务 openclaw 的日志： docker logs -f openclaw-enterprise-openclaw-1 。常见错误是LLM服务（Ollama）连接不上，日志中会出现 Failed to call model 等字样。
      4. 检查Ollama服务是否运行，模型是否加载： curl http://localhost:11434/api/tags （在宿主机执行）。
      5. 如果以上都正常，可能是工作流配置错误或某个Skill执行超时。查看OpenClaw日志中关于具体工作流执行的记录。
    • 核心技巧 ：为每个用户请求生成一个唯一的 trace_id ，并让这个ID在网关、OpenClaw核心、各个Skill之间传递。这样，在分布式日志中，你可以用这个 trace_id 轻松串起一个请求的完整生命周期，极大提升排查效率。

从30个场景的构思，到一步步部署、配置、集成，再到最后的优化与运维，构建企业级OpenClaw应用是一个系统工程。它考验的不仅是技术集成能力，更是对业务流程的深刻理解和对稳定性、安全性的严谨把控。我的体会是，从小处着手，选择一个痛点明确、价值易衡量的场景（比如自动会议纪要）进行试点，快速跑通闭环，让团队看到实效。然后再逐步扩展技能库、连接更多系统、优化复杂流程。在这个过程中，你会积累下一套属于自己企业的“自动化资产”，这才是OpenClaw带来的最大长期价值。最后分享一个小心得：文档和代码同样重要。为每一个自定义的Skill和工作流编写清晰的使用说明和配置文档，这会在团队协作和后续维护中节省你无数的时间。

# AI智能体
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

百万Token不是数字游戏：Kimi K3完整吞下10万行代码库后，我测出了它的真实理解力

avatar 亚马逊云科技技术品牌专区
cover

【2026最新版】Codex换肤助手下载和使用教程：一键美化 Codex 客户端，支持自定义主题

avatar 亚马逊云科技技术品牌专区

FastAPI + OpenAI 兼容协议 + DeepSeek 实战：大模型 Function Calling 工具调用全拆解

模型本身不能直接查天气、查数据库。我们告诉模型"你有这些函数可用"，模型在觉得需要时返回"我想调用某个函数、参数是这样"，真正的函数由我们本地执行，再把结果交还给模型整理成话。这就是"模型决策 + 本地执行"的混合模式。

avatar 亚马逊云科技技术品牌专区