阅读说明
本页是综合讲解后半部分的中文译文，接续工作流映射与组织知识。先呈现讲义中的工具连接，再保留生成图像、3D 场景与整理示例票据的口头讲解。
这里描述的是原演示，不代表网站实际运行了这些工具，也不提供原账户、密钥、私人文件或带身份的截图。产品界面、型号和功能可能变化，复现前需要查相应版本。
讲义一：无代码工具与连接能力
原工具图列出 Make、Claude、Perplexity Computer、n8n、Zapier、ChatGPT Agent、Cowork、Manus、Hermes Agent 和 ZeroClaw 等名称，用来展示不同自动化与 Agent 方向。
它们不属于完全相同的产品类别，也不是一个永久有效的能力排名。选择时应检查任务、数据、权限、维护与费用，而不是只比较名字。
讲义二：API 与 MCP
API 定义软件怎样请求信息或动作：应用发出请求，外部系统处理，再返回响应。调用方不必知道服务内部全部实现，但需要遵守接口与权限约定。
MCP 为 AI 应用发现和使用外部能力提供共同方式。没有连接时，系统可能只能说明步骤；有合适工具连接和授权以后，才能读取相应信息或执行动作。
API 面向具体功能，MCP 则可以作为统一能力接口；服务端背后仍可能调用 API。因此，MCP 不替代 API，也不是连接以后就拥有对方全部功能。
查看图解文字说明
宿主是 AI 应用，负责管理模型使用方式和多个客户端。图中客户端 A 连接资料服务端，客户端 B 连接工单服务端；服务端可以暴露工具、资源或提示。连接方式统一不表示访问范围、事实与执行安全自动得到保障。
图中权限、客户端和服务端仍然分开。哪些能力公开、哪些请求可以执行，取决于实际配置。
口头文字稿一：从现成工具开始
无代码和 Agent 工具让没有完整开发背景的人也能试验，开发人员也可以用它们减少重复操作，把精力放在关键决定上。
原讲解计划使用 Make、Claude 等工具，也提到可自管的 Agent 路线。它先回到 API，说明不同软件怎样交换资料、使用对方服务。
在工作流平台里连接模型
演示打开一个已有的社交内容工作流，通过连接配置接入模型和其他工具。工具所需的访问凭据来自对应服务账户，再按平台要求安全配置。
原演示临时创建了一个用于示范的 API 密钥，复制到连接设置，随后清理。文字稿没有提供可公开使用的凭据，本页也不展示任何真实值。
译注：原讲解把密钥比作地址或电话号码，容易混淆。API 是接口，端点地址说明访问哪里，密钥则通常用于识别或授权请求，应当作为凭据保护。短期使用也不意味着所有平台都支持自动到期，应核对实际机制并在不再需要时撤销。
过去，接入 API 往往需要开发人员专门处理接口；演示强调，许多现代平台已经把常见连接做成配置入口，让试验更容易。但预制连接并不免除认证、接口变化和错误处理。通过接口，模型、消息工具和其他服务可以在同一流程中工作，减少人工切换。它们没有被“装进”同一个模型，仍是通过网络和应用逻辑交换请求与结果。
口头文字稿二：用 MCP 连接图像工具
原演示在聊天应用的连接器设置中，找到外部图像工具并重新授权。授权完成后，要求生成一张写实赛车图片，并明确使用对应工具。
应用先识别可用连接，准备更具体的图像提示，等待确认后发起生成。演示中一度出现显示问题，随后尝试从工具结果返回图像。
这说明对话可以成为工具入口，但请求已发出、服务已受理、图像已生成、结果能显示，是不同状态。文字稿不能证明最终图像满足了全部要求，本页不把未取得的原图当作已经复现。
讨论中另有一个应用思路：在本地网页应用中接入图像或语音服务的 API。它说明本地界面也可以使用外部能力；“界面运行在本地”与“模型处理也在本地”仍须分开判断。原讲解说连接以后聊天应用“拥有全部能力”，需要收窄理解：它只能使用服务端实际公开、账户有权使用且宿主支持的那部分功能。
口头文字稿三：用 MCP 操作本地 3D 场景
接下来，演示从云端图像工具转向本地 Blender。Blender 是开放源码的 3D 制作软件，但实际建模仍需要知识与练习。
演示环境已经配置了连接组件与本地服务，让聊天应用能够通过 MCP 操作场景。原讲解在界面中看到相关设置，不代表每一份 Blender 安装都默认自带同样组件。
请求是：先清空示例场景，再制作一把维多利亚风格椅子。也可以提供照片、插图或摄影测量资料作为参考；完整场景还涉及对象、材质、灯光等不同部分。
译注：清空场景是修改操作，只应在明确的演示副本中执行并保留可恢复版本。生成一个看起来像目标的模型，也不等于建立了具有工程精度或真实状态同步的数字孪生。
这个例子展示，本地应用也可以接到 AI 工具流程中。与云端服务相比，执行位置不同，但资料是否离开设备，仍取决于整个调用链，而不是只看 Blender 在本地运行。
口头文字稿四：授权身份、组织治理与资料位置
原讨论提出一个实际问题：发布带连接的 Agent 时，究竟使用最终用户的权限，还是制作者的权限？这会影响谁能够读取和执行什么，也影响治理与使用便利。
组织首先需要避免未经批准的影子 AI。个人能够登录某项工具，不代表有权把组织资料交给它处理。还要看资料用途、合同、行业规则和服务条件。
原讲解用员工把内部代码交给聊天工具分析的新闻例子，说明知识产权与资料外传风险。保存材料未完整确认该事件来源，所以这里保留的是判断问题，不把叙述当成经过验证的事故报告。
云端处理可能意味着资料传到服务商，但不能据此认定所有云服务都会拿资料训练，或所有商业闭源模型都不能用于组织。不同产品、合同、保留设置和访问方式需要分别检查。
本地或自管模型是一条可选择路线，也会有设备、更新、权限、日志和备份方面的要求。开放权重不自动等于安全，全部在本地也不自动等于已经满足所有治理条件。
原讲解偏好对敏感资料采用本地方式，这是其实施取向；适合哪个组织，应根据实际威胁、资源与条款判断。
口头文字稿五：先说明票据 Agent 的目标
下一个示例是票据整理。希望把照片、扫描件和邮件 PDF 放进收件文件夹，系统就能识别新文件，提取日期、商家、金额、币种、类别、账户、税项和付款线索。
随后重命名、分类并放到合适文件夹，更新费用表，再把无法确定的问题留给人。原讲解提到 Excel、会计软件或合并 PDF 等交付形式，取决于实际使用者需要。
这不是让系统替代所有会计工作，而是辅助整理资料。演示中使用的是虚构票据；原讲解也区分了为展示方便使用的云端工具与其实际部署偏好的本地路线。
初始项目描述
原演示先创建一个项目，用简短目标说明：把票据的照片、扫描与邮件 PDF 变成会计可以使用的记录；区分业务和个人，按会计年度与费用类型归档，明确命名，并在表格中记录建议类别。
把资料、目标和指令保存在项目里，可以减少重复解释，但不能默认应用永远记住全部内容。具体上下文、文件访问与记忆方式仍受产品实现限制。
原文字稿对演示时选择的模型名称有不清楚的转写，因此不猜测版本。讲解表达的是使用较合适的计算等级控制投入，而不是所有任务都选最昂贵的配置。
口头文字稿六：把规则写成可执行要求
原演示随后加入更具体的指令。这里保留其中的知识性要求，目录名用示意名称表示。
- 这是票据与费用资料库，新资料放进收件目录；执行前先查看可用背景和目录。
- 如果一个 PDF 包含多张票据，应当把每张分别识别并保存对应记录，同时保留原件。
- 读取日期、商家、购买项目、总额、税项和付款线索，例如付款卡末四位；不得收集不必要的完整卡号。
- 根据已确认规则区分业务和个人。没有明确付款线索时，可检查账单名称或收件地址，但仍须核对。
- 业务票据按实体、会计年度与类型归档，个人票据按相应年度整理。
- 用清楚规则命名文件，把业务项目加入费用表。
- 不要猜测。不确定时移到待审位置，在备注写出问题；不要删除原始文件。
- 完成后说明处理数量、各类别合计和待回答问题。
- 人确认的修正可以形成新规则，保存在业务说明或规则文件，并在适当范围内用于以后执行。
译注：付款卡只是线索，不足以单独决定业务性质或税务处理。会计年度、实体关系与费用分类应由实际规则和具备相应知识的人确认；这段描述用于解释流程设计。
原演示把本地示例目录连到应用，然后只发出短请求：“按照项目指令，处理文件夹中的票据。”请求可以很短，是因为详细边界已经在项目里；不是因为系统天然知道应该怎么做。
口头文字稿七：执行前怎样补足缺少信息
执行开始后，工具列出准备步骤：读取 20 张示例票据，分类、归档和重命名，建立费用表与业务说明，再检查并汇总。
它没有直接假定会计年度，而是询问年末日期；演示回答采用 12 月 31 日。它还询问哪些示例付款卡属于业务。原讲解指出，这些可以提前提供，但特意留空后，系统是否会询问，就成为一个有用观察。
“不清楚先问”因此是实际要求，而不是最后才加上的口号。取得文件夹权限也不代表可以任意改动电脑其他位置，执行范围仍应受限。
原演示等待处理时，再次讨论云端与本地的选择。把财务资料交给云端之前，需要确认权限与处理条件；若采用本地系统，也必须检查模型、应用与其他连接是否仍有外部传输。
口头文字稿八：查看结果，再测试纠正
原演示随后展示：原始文件仍在，新增了业务与个人目录，业务内容按年度与类别分开，同时建立表格。
这只是演示者看到的界面结果，不足以证明全部字段和合计都正确。真正验收还应比较原件数量、提取值、重复与遗漏、分类依据及表格内容。
接着，演示者挑选一张原先归为个人的餐饮票据，说明它实际属于业务费用，观察系统怎样修正目录、表格和规则文件。
执行过程中发生了命令失败和文件覆盖问题。原演示推测可能因为表格仍被打开，并出现请求允许删除文件的界面；之后又产生了更新版本的费用表。
译注：这暴露出原演示中的重要张力：前面的要求是保留原件，但后来出现较宽的删除授权。不能把直接批准永久删除当成推荐步骤。可靠实现应区分原件与派生文件、缩小修改范围、保留备份，确认更新的是正确版本，并检查纠正是否完整。
原讲解打开业务说明，看到“已学到的规则”区域，把修正用于后续判断。这里的“学习”指保存和重用规则，不必涉及模型重新训练。新规则还应写明适用对象，避免把一次例外推广到所有餐饮票据。
口头文字稿九：让流程持续运行
项目可以继续接收指令，也可能按实际产品支持设置每天、每周等执行方式。但定时启动、文件权限、失败通知和模型调用都需要单独实现，不能只在对话中说一次就假定已经设置成功。
不清楚时提出问题，是人在循环中的一部分。原讲解还提到进一步制作待审界面：打开无法识别的票据，人工修正日期或其他字段，保存后再纳入系统。
把付款邮件导出到指定目录，整理后再交付资料，能够减少一些月底集中处理的压力。原讲解称其实际系统已运行一年多，明显减轻了集中整理的压力。这是个人实施体验，不能替代独立测量或保证所有组织得到同样效果。
电脑与手机怎样连接
原讨论最后提到，应用可以有网页界面，部署在自己服务器、云端或内网，再按权限从手机访问。桌面上的项目也可能支持移动入口，但具体行为取决于产品。
能从手机看到聊天，与手机直接获得本地文件权限，不是同一件事。选择部署位置时，需要同时考虑访问方式、资料边界与持续运行，而不只看界面是否方便。
从演示到可验证系统
这组例子把目标、资料、规则、工具、执行和人工纠正连接起来。它展示了值得研究的做法，也展示了失败、权限与覆盖问题。真正使用时，应把“工具说完成了”与“记录已经核对正确”分开，保留原件和可恢复过程。
关联阅读
先读工作流映射与组织知识理解规则从哪里来；协议的正式概念见MCP 与 API。
参考与延伸阅读
以下为编辑补充，具体复现条件以实际版本与文档为准。
- Blender 官方手册：英语，查询场景、对象和软件操作；MCP 连接还需核对所用组件。
- MCP 官方架构：英语，查询宿主、客户端、服务端与能力边界。
- Make 帮助中心：英语，查询连接、凭据和工作流运行。
- OWASP：生成式 AI 安全：英语，了解工具调用、资料处理与应用安全风险。