Tangly AI 实践与实验 https://www.tangly1024.com/ Tangly1024 Wed, 14 Oct 2026 14:30:27 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2026, Tangly <![CDATA[Magpie 与 CC Switch 怎么选？一个统一模型入口，一个多 Agent 配置台]]> https://www.tangly1024.com/article/magpie-vs-cc-switch-model-routing-and-agent-config https://www.tangly1024.com/article/magpie-vs-cc-switch-model-routing-and-agent-config Wed, 30 Sep 2026 00:00:00 GMT

Magpie 与 CC Switch 怎么选？一个统一模型入口，一个多 Agent 配置台

当电脑里只有一个编码 Agent 时，模型设置往往只是一次性的工作。等我同时使用 Codex、Claude Code、MiniMax Code 或 OpenCode，问题就变成了：每个客户端各有自己的配置文件和登录方式，换模型、改 API 地址、迁移 MCP 时，我到底要改几处？
我最近看到 Magpie 和 CC Switch 都在解决这类麻烦。它们界面上都有供应商、模型和一键切换，容易让人觉得是同一种工具。把两者的项目说明认真拆开后，我更愿意这样概括：Magpie 把多个模型供应方收进一个本地网关，再让不同 Agent 选择它；CC Switch 以管理各个 Agent 自己的配置为中心，也提供本地路由等扩展能力。
本文说的 Magpie，特指 yetone/magpie 及其官网 usemagpie.ai，是模型选择和 API 网关项目；不是同名的 Apache Magpie 项目。Magpie 部分依据截至 2026 年 9 月 30 日的仓库说明；CC Switch 的具体工具差异以 v3.20.4 发布说明为参照。这是公开资料对比，不是我在同一台机器上的实测排名。

先把“切模型”拆成两件事

有时我说想“换个模型”，实际可能是两种不同工作：
  1. 想让 Claude Code、Codex、MiniMax Code 都能使用同一组供应商和模型，希望不用逐个客户端复制地址与密钥。
  1. 想维护每个 Agent 的本地配置，还希望在一个地方管理 MCP、Skills、提示词和项目配置。
第一种更接近统一请求入口，第二种更接近统一配置台。Magpie 和 CC Switch 都能处理一部分重叠需求，但默认重心并不相同。
我会把“管理器是否在每次请求路径上”作为一个更直观的区分：
维度
Magpie
CC Switch
核心路径
本地网关统一接入模型供应商，客户端从统一模型目录选择 provider/model
直接管理多个客户端的供应商和配置；可选启用本地路由
模型请求
网关能接收多种 API 格式并做协议转换，再转发给所选供应商
可直接切换供应商；启用 Local Routing 后还能做路由、故障切换等处理
常用设置
每个 Agent 的模型、部分推理档位、供应商目录，以及跨 Agent Profiles
受支持工具的供应商配置，并按工具管理部分 MCP、Skills、提示词、项目和会话；具体项目因工具不同
管理方式
菜单栏/桌面窗口、TUI 和 CLI 都能改模型与供应商
桌面控制台集中编辑和同步配置，部分切换支持系统托盘
公开支持范围
项目 README 列出较多 Agent，包括 Codex、Claude Code、MiniMax Code、DeepSeek Harness 等；是否显示取决于本机安装和配置
v3.20.4 说明已把 MiniMax Code 纳入十个受管工具；每个工具的功能并不完全相同
更适合先解决
“一个模型目录怎样供多个 Agent 使用？”
“多种 Agent 配置怎样一起维护？”
这张表是工作重心对比，不代表任何一方完全不具备另一边的能力。CC Switch 已有本地路由能力；Magpie 也能备份和恢复其管理的指令、MCP 与 Skills 资料。值得比较的是你每天最常遇到的那类操作。

Magpie：让不同 Agent 走同一个本地模型入口

Magpie 的主要路径是先添加供应商，再让 Agent 从 Magpie 的模型目录里选择模型。它在本机启动网关，对客户端提供 OpenAI Chat Completions、OpenAI Responses、Anthropic Messages 等接口；客户端把请求发给本地网关，Magpie 再按选择转发或转换协议。
这样做带来一个比较清楚的模型入口：多个客户端可以使用同一批供应商模型，部分已登录 Agent 的订阅也能作为其他客户端可选的模型来源。不过 Magpie 官方说明特别提到，Claude 订阅请求若由其他 Agent 调用，Anthropic 可能把它识别为第三方流量；我会先核对对应服务条款与账号风险，再决定是否采用这条路径。它还有跨 Agent Profiles，可以把一组模型设置保存下来，在工作、个人或成本优先等配置之间切换。
如果我想在 Codex 里试一个其他供应商的模型，又不想把同一套供应商逐个手抄到 Claude Code 和其他客户端，Magpie 的统一目录和网关就比较贴合这个问题。它还列出 provider/model 选择、模型列表刷新、路由组和 API 调试视图等功能。
这条路线也意味着要弄清楚请求实际去了哪里。网关能处理经过它的请求内容和工具调用结果；使用订阅账号或自定义供应商时，我会核对其服务条款、认证路径和凭据保管方式。Magpie 的项目说明称它在本机运行、凭据保存在本地配置中；这是项目方说明，我仍会在自己的环境中检查网络目标和进程行为。

CC Switch：把各个客户端的配置放到一处维护

CC Switch 常见的使用顺序是导入现有设置、添加或选择供应商，再把配置应用到相应的客户端。它公开列出的工具包括 Claude Code、Codex、MiniMax Code 等；同时提供 MCP、Skills、提示词、项目配置和会话管理等面板，但这些能力不是每个工具都齐全。
在这个设计里，配置通常仍然落回每个客户端理解的文件或目录。比如给不同工具分别启用 MCP，或把提示词写到对应的 CLAUDE.md、AGENTS.md 一类文件。切换完成后，有些客户端需要重启才能读到更新。CC Switch v3.20.4 的说明特别提到：MiniMax Code 可在 CC Switch 中管理供应商、MCP、Skills 和提示词，但它的默认模型、登录、删除会话仍由 MiniMax Code 自己负责；该版本对 MiniMax Code 也不支持 CC Switch 本地路由、故障转移或 Profiles。这个例子说明“出现在支持列表”不等于所有能力都完全一致。
CC Switch 还可以对支持的工具开启本地路由，为请求做格式转换、路由或故障切换。因此，我不会把它简化成“只会改几个配置文件”。开启本地路由时，请求也会经过本机代理，并可出现在请求日志里；关闭时，供应商配置通常直接写进工具配置。更准确的说法是：它以多 Agent 配置管理为中心，再把请求路由和其他工具面板纳入统一桌面应用。

我会怎样判断先试哪一个

我现在的摩擦
我会先验证
观察什么
每个客户端重复填写供应商、地址和模型
Magpie 的统一模型目录与本地网关
客户端连接步骤是否减少，切换后是否确实用了预期模型
经常切换一整套工作/个人配置
Magpie 跨 Agent Profile；或 CC Switch 面向 Claude Code/Codex 的项目快照
保存的模型、端点和其他设置范围不同；核对覆盖项与回退方式
MCP、Skills 和提示词散落在不同目录
CC Switch 的管理面板；同时对照 Magpie 的 library/backup 能力
同步范围、每个工具的支持差异，以及是否覆盖了原文件
不同客户端需要不同 API 协议或路由
两者各自的本地路由路径
请求是否正常流式返回、工具调用是否兼容、失败如何显示
只是偶尔改一个模型
先用客户端自己的设置
是否真有重复操作，是否值得再加一个配置层
我会拿一个低风险任务做短试验：保留原配置副本，添加一个测试供应商，只在一个 Agent 上切换，发送一条不含私密代码的请求，确认模型、端点、工具调用和恢复方式。再决定要不要把同一方案扩展到其他客户端。
我不会让两个管理器长期同时改同一份客户端配置。这是从两者都会写入 Agent 配置推出来的维护判断，不是官方宣称二者不能共存。试用时先选一个作为这份配置的主要写入入口，能减少“刚切完又被另一个工具改回去”的排查成本。

我的判断：先定位摩擦，再比较按钮

如果我的核心问题是“模型和 API 到处散落”，Magpie 的统一网关更值得先看；如果我的核心问题是“MCP、Skills、提示词和 Agent 设置难以同步”，CC Switch 的桌面管理方式更直接。若我只是每周换一次模型，客户端自带设置可能已经够用。
我会把它们看作两个可以交叉的工具方向：一个更关注模型请求如何进入不同 Agent，一个更关注每个 Agent 的设置如何被集中维护。工具越多，越需要先确认配置的归属、请求经过谁、如何备份和怎样回退。把这些问题说明白之后，“装哪个”就从功能清单变成了一个具体的工作流选择。

参考资料

资料核对日期：2026-09-30。Magpie 和 CC Switch 都在持续更新，支持工具、各客户端可管理字段和路由行为以安装版本的说明为准。本文未进行同环境实测，不对速度、质量或兼容性作排名。
]]> <![CDATA[Codex、Claude Code、MiniMax Code、DeepSeek Harness 默认工作流对比：按常见入口理解差异]]> https://www.tangly1024.com/article/compare-default-workflows-codex-claude-code-minimax-code-deepseek-harness https://www.tangly1024.com/article/compare-default-workflows-codex-claude-code-minimax-code-deepseek-harness Wed, 30 Sep 2026 00:00:00 GMT

Codex、Claude Code、MiniMax Code、DeepSeek Harness 默认工作流对比：按常见入口理解差异

同一句“帮我修好这个登录问题”，放进四种编码 Agent，开始工作的方式并不一样。有的先选项目和运行环境，有的从当前终端目录读取仓库，有的先附加本地工作区，还有的要先启动 Harness、配置模型并选择 workspace。
我想比较的不是模型谁更聪明，也不是哪一个能少写几行代码。我更关心一项任务从哪里开始、Agent 怎么拿到项目上下文、执行过程中如何请求权限，以及最后怎样把结果交还给人。
本文比较的是几种常见入口：Codex 桌面应用/CLI、Claude Code CLI、MiniMax Code 桌面应用、DeepSeek Harness Web UI。这里的“常见工作流”不是四款产品共用的固定默认值；产品版本、入口、仓库配置和权限设置都会改变实际行为。以下内容依据截至 2026 年 9 月 30 日可读取的官方产品文档整理，没有声称我在同一代码库里完成过四款工具的对照实测。

先把比较边界说清楚

Codex 有桌面应用、CLI 和 IDE 等入口；Claude Code 以终端交互为代表，也有其他运行方式；MiniMax Code 是桌面 Agent 应用；DeepSeek Harness 则是可配置的 Agent 运行框架，也提供 Web UI 和预览形态。它们不是四个只换了颜色的聊天框。
为了让比较有用，我把路径统一成五个问题：
  1. 从哪里发起一项任务？
  1. 项目文件和规则怎样进入上下文？
  1. Agent 如何规划、调用工具并迭代？
  1. 哪些动作会停下来等待确认？
  1. 我如何看到改动并决定是否接受？
产品入口
常见起点
上下文从哪里来
执行循环的特点
人主要检查什么
Codex 桌面/CLI
桌面：选择项目并开任务；CLI：在项目目录启动会话
选定的仓库、当前或独立工作树、项目说明与附件
计划、编辑、运行工具、观察结果、修复，再重复
运行结果、差异、权限请求与是否达到验收条件
Claude Code
在项目目录启动 claude 并描述目标
当前目录、仓库说明和会话配置
定位代码、理解上下文、实现变更、按需要运行测试
文件改动、终端动作和 permission mode 下的请求
MiniMax Code 桌面
附加本地工作区后，从任务输入框描述目标
已附加的本地项目、会话内容和项目规则
用文件、终端、浏览器预览逐步实现与调试
Changes/diff、命令结果、预览及当前权限策略下的确认
DeepSeek Harness Web UI
启动 Web UI、配置模型并选 workspace（项目目录）后发起 session
启动目录、明确选择的 workspace、所启用 profile/plugins（工具组合）
由所选 Harness profile 提供读写、shell、搜索、计划和可选子 Agent
当前权限策略、所用插件与工作流版本、文件和命令结果

Codex：把项目、任务和执行环境一起组织起来

在 Codex 的常见桌面使用路径里，我先选择项目和执行环境，再给一项任务和它的验收条件。如果改动需要隔离，我可以为线程使用 Git worktree；如果只是快速查看，也可以继续在本地工作区处理。Plan mode 可以先生成可审阅的步骤，再进入修改。
一个较长的 Codex 任务通常会经历：理解仓库、形成计划、编辑代码、运行检查、观察日志、修复问题，再汇报状态。它强调的是可以持续推进的任务循环，而不是只生成一份代码建议。CLI 与 IDE 上能用哪些环境和权限，由相应配置决定；例如 Codex 配置文档给出 workspace-write 和 on-request 作为常见配置值，但我不会把它们概括成每个 Codex 表面的强制默认值。
我会在完成后看文件差异和验证记录。如果改动跨文件或需要并行处理，worktree 能让代码状态更清楚；代价是要选对基线和工作区，不能把“启动了新线程”误当成“自动隔离了一切”。
这条路径的特点：任务和运行上下文结合较紧，计划、终端反馈与变更审查构成连续循环。对我来说，任务描述中的“完成标准”以及最后的差异检查尤其重要。

Claude Code：从当前项目目录进入终端 Agent 循环

Claude Code 的入门流程更像在项目目录打开一个 Agent 终端：运行 claude，说明希望达成的结果，让它定位相关代码、理解上下文、实现修改，并在适当时运行测试。继续一个工作时，可以恢复当前目录最近的会话或通过会话标识重新打开。
权限行为不宜用一句“默认全部自动”或“每步都要批准”概括。当前官方 Quickstart 对 Claude Code v2.1.283 及以上的交互式终端会话说明：内置起始权限模式是 Auto mode，由分类器审核动作，大多数文件编辑和命令可以不逐项询问；更早版本在 Pro、Max、Team 方案中才以内置 Auto mode 起始。用户设置或组织策略可以改掉起始模式。Auto mode 也不等于 acceptEdits，不同权限模式的审核方式并不相同。
它的工作节奏通常是对话与终端动作交替：我给目标，Agent 查看文件或运行命令，返回结果，再根据反馈继续。需要先对齐方案时，我可以切换到 Plan mode；任务结束时，可以让它解释改动或检查已有 diff，再由我决定是否提交。
这条路径的特点：终端和会话是主要工作台，适合已经在仓库里、习惯用自然语言驱动本地开发工具的工作方式。项目级 CLAUDE.md、允许目录和权限规则会明显影响实际体验。

MiniMax Code：围绕桌面工作区组织实现与复核

MiniMax Code 从桌面首页的 composer 开始。我可以附加一个本地项目，选择 Coding mode，再说明目标；之后 Agent 在同一工作区里读项目、编辑文件、运行终端命令，并用内置浏览器预览页面。
这条路把对话、文件变化、终端和预览放在同一个任务空间。复杂任务可以选择 Agent Team 来分解与并行推进，但它是扩展能力，不代表每个普通任务一开始就会自动拆成多 Agent。官方权限文档列出的可能需要批准的动作包括读取工作区外的文件、编辑或删除文件、运行命令和产生外部副作用的工具；是否弹出确认取决于当前权限策略。我仍会检查 Changes 面板、运行结果和浏览器行为，再判断这次改动是否完整。
这条路径的特点：桌面工作区同时承载项目上下文、执行工具和成果检查。对视觉页面或需要频繁预览的任务，文件与浏览器反馈在一个界面里比较直观；复核时仍要回到实际差异和测试结果。

DeepSeek Harness：先确定运行配置，再让 Agent 开始工作

DeepSeek Harness 的流程多了“运行时配置”这一层。当前官方 Web UI 快速入门要求先启动服务，在 Settings → Models 配置模型，再通过 Choose workspace 加入项目目录。选好 workspace 后，session composer 才能开始接收任务。
Harness 能做什么，取决于当前启用的 profile 和插件；profile 可以理解成一组运行规则与工具组合。Web UI 会依据正在使用的权限策略，对需要批准的操作提出确认。因为它允许替换运行组合，我会记录所选 profile、插件和权限策略；同一个 Harness 名称不保证始终对应完全相同的工具集合。
这和直接启动一个相对固定的产品界面不完全相同：Harness 把模型、工具、会话、沙箱、工作循环和 UI 拆成可组合部件。灵活性意味着我需要在复现问题时记录选了哪个 profile、启用了哪些插件、权限策略是什么。官方 README 当前仍标注 Developer Preview，并提醒会有兼容性变化。
这条路径的特点：先配置 Agent 如何运行，再配置它在什么 workspace 工作。它适合希望理解或调整 Harness 组成的人；如果只想尽快完成一个小修复，初次配置也可能多出几步。

真正影响体验的是五个交接点

我把四种流程放在一起后，发现选择工具时最值得比较的不是宣传里的“全流程”，而是五个具体交接点：
交接点
我会问的问题
项目上下文
我是否清楚 Agent 正在读哪个目录、哪些项目说明会生效？
任务状态
长任务能否看到计划、已完成步骤和待解决问题？
执行环境
文件改动、终端、浏览器或 worktree 是怎样关联起来的？
权限确认
哪些动作会等待我，配置是否会改变这个边界？
验收证据
我能否看到真实 diff、运行结果和失败后的恢复路径？
如果我想把四款工具做成一次有参考价值的小实验，我会使用同一个可丢弃分支、同一份任务说明和同一套验收标准。记录首次得到有效结果的时间、澄清次数、越界改动、验证结果、恢复成本，而不只比较最终回答看起来是否流畅。模型、账户、版本与设置也要记下来，不然观察结果很难复现。

我会给四种工具同一张任务卡

我会让每个 Agent 在各自的干净副本中处理，然后审查 diff 和检查结果。若某一款需要先安装、附加工作区或启用插件，这些准备时间也属于实际工作流的一部分，可以另外记录。

我的结论：选一条适合自己复核的循环

Codex 把任务线程、运行环境和差异审查连成一条持续执行路径；Claude Code 从当前项目目录和终端会话切入；MiniMax Code 把项目、文件、命令与预览放进桌面工作区；DeepSeek Harness 让人先配置模型、workspace 和可组合运行能力。
我不会把某一条路径称为普遍最佳。对于短任务，启动成本和项目上下文最关键；对于持续开发，状态可追溯、权限边界和恢复能力可能更重要。选工具时，我会先看自己能否清楚回答：它现在用的是什么代码、接下来会运行什么、哪些动作需要我确认，以及我凭什么认定工作已经完成。
AI Agent 把执行带进了开发流程，但“完成”仍需要可见证据。对我而言，一条可靠的工作流不是少一个按钮，而是让输入、执行、检查和交接都能看得见。

参考资料

资料核对日期：2026-09-30。Codex 各入口、Claude Code 权限配置和 DeepSeek Harness profile/plugin 组合会影响实际行为；本文比较公开使用路径，不是统一环境的性能或代码质量测试。
]]> <![CDATA[AI 企业工作流任务单怎么设计？以会议纪要转任务为例]]> https://www.tangly1024.com/article/ai-enterprise-workflow-meeting-notes-to-tasks https://www.tangly1024.com/article/ai-enterprise-workflow-meeting-notes-to-tasks Wed, 30 Sep 2026 00:00:00 GMT
会议结束时，大家往往觉得“事情都说清楚了”。过两天再回看纪要，才发现有人记住了方向，却没人确定负责人；有人说了“尽快”，却没人说清日期；有些决定只是讨论中的备选方案，却被写成已经拍板。
我一直对 AI 工作流感兴趣，因为一个人和小团队每天都在做信息交接。会后整理就是一个很具体的入口：AI 能不能帮我把长段对话变成结构清楚的待确认任务，让真正负责的人少做重复摘录，同时保留决定权？
这篇文章设计的是一个可供试验的流程，不代表我已经接入某个真实企业会议系统。它的核心不是让 AI 代替会议参与者，而是把遗漏的行动项照亮，让每项任务都有来源、状态和确认的人。

从“写得像纪要”到“任务可以接着做”

传统纪要主要复述讨论。后续工作还要再从长文字里找出：究竟要做什么、谁来负责、何时完成、依赖什么、这件事是决定还是建议。
所以我会把自动化的目标定义成一个标准任务对象，而不是一篇更漂亮的会议摘要：
这里的空日期很重要。原话只说“下周”，没有确定哪一天。系统不能为了填满表格而自行选一个日期，应该把它作为待确认的问题交回参会者。
我会把这段要求写进提示词，而不把准确性寄托在“语气严谨”上：
这段提示词只负责让输出遵循约定。后面的字段校验和人工确认仍然必要。

我会把工作流拆成六步

1. 授权读取：只读取允许处理的会议内容和参与者信息。涉及客户、员工、合同或经营数据时，先确认组织规则、数据权限和保留周期。
2. 提取行动项：模型识别候选动作、负责人、期限、决定状态和上下文。每条候选任务尽量附上对应原句，减少读者来回翻找。
3. 校验字段：用确定规则检查任务是否有动词、负责人是否存在于参会名单、日期是否明确、是否与其他事项重复。模型负责找候选，规则负责发现格式问题。
4. 人工确认：参会者或会议主持人确认动作是否真的成立、负责人是否同意、期限是否准确。没有答案就保持“待确认”，不把推断伪装成决定。
5. 创建任务：只有确认后的条目才写入任务系统。第一轮试验可以先输出到待审批表格，不自动分派、催办或通知外部对象。
6. 留下来源记录：任务卡保留会议日期、来源片段和确认人。发现误提取时，可以回到上下文修正，而不是只看到一条来历不明的任务。
这个设计把生成式判断和确定性检查分了工。它仍然需要人处理语义问题，但可以减少手工从纪要复制标题、负责人和背景的步骤。
如果目标系统是任务看板或数据库，我会按下面的逻辑映射字段，不假设任何特定产品的字段名称：
草稿字段
任务系统中的落点
写入规则
action
任务标题/描述
由确认人核对后创建
owner
负责人
只从授权参会人/成员列表选择
due_date
截止日期
null 时先提问，不擅自填默认日期
status
任务状态
初始放入待确认队列
source_quote
来源/备注
与会议日期一起保存，支持追溯
dependencies
前置任务/备注
未确认时不自动阻塞其他工作

用一个小例子走完确认环节

假设纪要里有三句话：
先挑十条物流咨询做内部试验。王敏愿意帮忙核样本。我们下周尽量开始，周五再看是否扩大。
AI 可以提出三个候选：
候选任务
负责人
时间
状态
为什么这样标
挑出十条物流咨询
未指定
未指定
待确认
原句没有说明由谁筛选、何时完成
核对十条样本
王敏
未指定
待确认
“愿意帮忙”不一定等于正式接下任务
周五评估是否扩大试验
未指定
周五（需确认具体日期）
待确认
“再看是否扩大”是评估约定，负责人不明
负责人可以补齐信息或删除错误候选。系统再把已确认项目变成任务，并在来源记录中保留原纪要位置。这样的流程看起来比全自动多一步确认，却能避免把讨论误写成承诺。

先在影子模式观察，再决定是否回写

我会先用一批经过授权和去敏处理的历史纪要做离线检查。AI 产出的任务只给人工看，不接正式任务系统。核对时至少统计这些情况：
  • 行动项找全了吗？有没有把讨论意见误当决定？
  • 负责人、日期和依赖是否来自原文？
  • 不明确的字段有没有老实留空？
  • 同一件事有没有被重复创建？
  • 人工确认一次需要多久，修改集中在哪些错误类型？
我会用这样的样例记录表，留下错误发生的原文和修正，而不是只记下一个总分：
样例编号
AI 提取结果
人工修正
错误类型
是否应交给人工
M-01
负责人为空、期限为空
会后确认负责人
信息缺失被正确保留
是
M-02
把讨论意见当成行动项
删除该候选
决议/讨论混淆
是
M-03
同一行动项出现两次
合并为一项
重复提取
是
这里的编号和结果是测试表的填写示例，不是已运行模型得到的数据。
只有常见错误已经看得见、可以修正，才考虑建立受控回写。最初可限制到一个项目、一类会议和一张可撤回的任务列表，再由主持人确认后创建。

怎样判断它有没有帮助

我会同时记录流程效率和信息质量，而不只看省了几分钟：
观察项
记录方式
纪要整理时间
从会议结束到任务进入可跟踪状态的人工时间
候选准确度
抽查行动项、负责人、日期和决定状态是否对应原文
未知处理
缺信息的字段是否被标出，而不是被猜出来
重复与遗漏
同一动作重复建卡、实际决定没有进入列表的例子
恢复能力
误建任务是否能撤回，故障后谁能继续手工处理
净节省可以先粗略算成：
如果任务更快出现了，但负责人和期限更常出错，那就不是有效改进。相反，如果 AI 没有完全减少人工时间，却能提供带来源的候选项，让遗漏更早被发现，这种价值也值得单独观察。

我会把哪些动作保留给人

会议记录不总是事实的完美文本。语音识别会听错专有名词，发言者也可能在讨论中改变想法。组织中的“谁答应了什么”更涉及责任，不应仅由模型推断。
因此，我会保留三个边界：AI 提议任务，不替人认领任务；它整理讨论，不自行改写组织承诺；它能在审批后写入内部草稿，不擅自通知客户、改变排期或触发付款。涉及敏感会议内容时，我会先按团队的数据和工具政策缩小处理范围。

AI 工作流的价值在信息交接处

会议纪要转任务只是一个小场景，但它让我看到企业工作流真正要解决的东西：不是把 AI 塞进每个软件，而是让信息在交接时少丢一点，责任在变化时看得见，错误发生后还能追回来源。
对我来说，一个值得继续搭建的 Agent 工作流，应该能说清楚输入从哪来、AI 做了什么、人确认了什么、结果写到哪里，以及失败后由谁接手。把这些事情讲明白之后，自动化才开始从演示走向可维护的工作方式。

参考资料

资料核对日期：2026-09-30。示例纪要与任务均为假设，字段结构可按实际使用的会议和任务系统调整；本稿没有声称已连接真实企业数据。
]]> <![CDATA[DeepSeek Harness 和 CC Switch 有什么区别？从 Codex 到 AI Agent 的工具分层图]]> https://www.tangly1024.com/article/deepseek-harness-cc-switch-ai-agent-map https://www.tangly1024.com/article/deepseek-harness-cc-switch-ai-agent-map Wed, 30 Sep 2026 00:00:00 GMT
最近看 AI 开发工具，我经常遇到一种混乱：Codex、Claude Code、MiniMax Code、DeepSeek Harness 和 CC Switch 会出现在相邻的讨论里，于是大家自然会问“它们谁更强”。可这几个名字有时根本不在同一层。拿一个配置管理器和一个 Agent 产品比，就像拿汽车的发动机、方向盘和修车工具比较谁更快。
我关心这件事，不是为了凑齐桌面上的 AI 工具，而是希望一个人也能有稳定的交付能力。工具越多，越需要知道它们分别管哪一段：谁负责理解任务，谁负责执行，谁提供模型，谁帮我维护配置。
我现在会用四层地图看它们。它不是性能榜单，而是一张“问题该交给哪一层解决”的路线图。

第一层：模型负责生成判断与内容

先把界面想象成一个工作台。你在里面提出任务，看到回答和操作过程；工作台背后接着模型。模型是执行链条中的重要部分，但它不会因为叫“模型”就自动知道电脑里有什么、能执行哪些命令、怎样保存进度。
因此，单独问“哪个模型最强”，往往没法回答实际的工具选择。模型表现还受上下文、任务定义、可用工具、权限和检查方式影响。相同的模型放在不同执行环境里，也可能呈现出不同的工作体验。

第二层：Agent 产品负责把任务变成一连串动作

如果一个工具能读取项目、规划步骤、调用工具、编辑文件，再根据结果继续工作，我们就不只是在和模型聊天，而是在使用一个带执行循环的 Agent。对读者来说，可以先把它理解成“会使用一套工作台的数字协作者”。
Codex、Claude Code、MiniMax Code 都可以从这一层理解。它们的入口、模型、工具、任务持续方式和项目上下文并不相同，但共同目标是让 AI 参与更完整的任务。Codex 的官方产品说明强调跨代码库完成工程任务；Claude Code 文档说明它能读取代码库、编辑文件、运行命令，并连接开发工具；MiniMax Code 的官方介绍也围绕项目上下文、计划、代码编辑和调试展开。
这并不意味着它们可以互换，也不意味着产品介绍就是独立的能力测评。官方资料说明“工具设计成什么样”，不自动证明“它在我的仓库、我的审美或我的任务上表现最好”。

第三层：Harness 管理 Agent 怎样持续工作

想象一位员工拿到任务后，还需要桌面、档案柜、电话、权限卡和交接簿。Agent 也需要类似的运行条件：怎样拿到上下文，怎样调用工具，怎样保留会话状态，怎样执行多步循环，哪里可以运行代码，失败后如何恢复。
这一组底层机制常被称为 Harness。DeepSeek 官方把它概括为模型之外的运行环境，并将 tools（可调用工具）、skills（给 Agent 的专门操作说明）、sessions（持续会话状态）、沙箱、存储、循环和调度等能力设计成可组合插件。2026 年 9 月 29 日，官网首页已展示可下载的桌面端，并将 DeepSeek Harness 标为 Public Preview；介绍的场景也扩展到日常工作、编码和研究。也就是说，它既是 Agent 运行框架，也是预览期的桌面工作台。公开预览不等于成熟度已经经过独立评估，插件和 API 仍可能变化，我会按具体版本体验后再判断稳定性。
把 DeepSeek Harness 和 Codex 比“谁更聪明”仍然容易错位：DeepSeek Harness 官网现在同时提供可直接使用的桌面 Agent 和可组合的运行框架；Codex 是 OpenAI 的编码 Agent 产品。它们的功能有交叉，产品入口与运行环境不同，不能只按一条“聪明程度”排队。

第四层：CC Switch 管的是多个工具的配置

还有一种麻烦更日常：电脑上装了几个编码 Agent，每个都有自己的 provider（模型/API 服务商）、MCP（连接外部工具和数据的协议）和配置格式。人为了换模型或配置，得在多个文件和设置页之间切换。这里的 skills 则是可复用的操作说明，告诉 Agent 如何按特定步骤处理任务。
CC Switch 是一个开源的桌面管理项目，项目文档列出 Claude Code、Codex、OpenCode、Gemini CLI 等支持对象，并提供 provider（模型/API 服务商）、MCP 与 skills 的统一管理功能。它解决的主要是“配置怎样更方便地维护”，不是替代这些 Agent 本身，也不是一个新模型。
这一区分让我能看清 CC Switch 解决的是配置维护摩擦。它的价值取决于我是否真的需要在多个工具和 provider 之间切换，而不是安装后自动产生效率。
把这几层排在一起，可以看到它们回答的是不同问题：
层次
它主要解决什么
我会先问什么
模型
生成、推理和语言/代码能力
当前任务需要哪类能力？
Agent 产品
如何访问项目、调用工具并推进任务
它能否在我的环境完成并交付？
Harness
Agent 如何管理上下文、工具和持续运行
我是否需要自行开发或组合 Agent 运行方式？
配置管理器
多个工具的 provider、MCP、skills 如何维护
我现在是否真的被重复配置拖慢？
这张表不用于给产品打分。它的用途是把问题送到正确的层：如果 Agent 的代码判断不够好，换一个配置管理器解决不了；如果只是每次手动改配置很麻烦，也未必需要重新开发 Harness。

把它们放进同一项工作，会发生什么

假设我想让 AI 修复一个仓库里的问题：
  1. 我写出目标和验收条件，Agent 产品（例如 Codex、Claude Code 或 MiniMax Code）读取项目并把任务拆成步骤。
  1. Agent 调用文件搜索、终端或测试等工具，读取结果，再决定下一步。
  1. 背后的 Harness 管理任务执行循环、上下文和会话状态；使用者可以逐步批准需要更高影响的动作。
  1. 如果我平时需要维护几个编码 Agent 的 provider、MCP 和 skills，CC Switch 这类管理器能减少重复配置；它不负责替 Agent 判断代码改得对不对。
这个顺序让“产品、底层运行机制、配置管理”的分工更直观。模型输出建议，Agent 把建议变成多步操作，Harness 维持操作过程，配置管理器解决工具之间的设置问题。某些产品会把几层能力打包在一起，但概念层面的职责仍然可以分开理解。

我会把哪些事情留给人

我不会把“能执行命令”当成“可以无限放权”。读取资料、提出建议、生成草稿，与发送邮件、删改正式数据、支付或发布产品，风险不在同一档。我的做法会是先给 Agent 只读上下文，再逐步开放有限写入；高影响动作保留人工确认，并保存可以复查的结果。
也要记得，处于 Public Preview 的产品、正式产品和第三方开源项目，各自的适用场景、支持方式和更新节奏都不同。配置方式、支持列表和许可条件也会变化。尤其是 provider、账号和服务条款，我会按服务提供方当前说明核实，不会把“工具能接入”推导成“任何接法都被允许”。

一张地图，比一张榜单更耐用

我现在会把工具问题拆成四问：模型负责什么，Agent 产品负责什么，运行 Harness 提供什么，配置管理又省下什么。这样遇到新产品时，我可以先判断它处在哪一层，再看它是否解决我手头的实际摩擦。
Codex、Claude Code、MiniMax Code 这样的执行入口值得按任务比较；DeepSeek Harness 值得观察 Agent 运行时如何被拆解；CC Switch 适合关注多工具配置维护的人。它们都可能有用，但不一定都需要出现在同一个人的工作台上。
对我来说，真正的 AI 工作台不是收藏最多工具的桌面，而是能把一件具体任务交给合适的执行层，同时保留清楚边界和验收证据的系统。

参考资料

资料核对日期：2026-09-30。DeepSeek Harness 当前页面状态以官网当日信息为准：它已提供 Public Preview 桌面端，插件与 API 仍可能迭代；产品功能和项目成熟度以后续官方文档与仓库发布记录为准。
]]> <![CDATA[AI 短剧的 30 秒开场怎么做？一份文生图、图生视频与剪辑路线]]> https://www.tangly1024.com/article/ai-short-drama-text-image-to-video-workflow https://www.tangly1024.com/article/ai-short-drama-text-image-to-video-workflow Wed, 30 Sep 2026 00:00:00 GMT
AI 视频最容易让人兴奋的地方，是一句话就能出现画面。也正因为如此，很多演示停在“生成一段很漂亮的视频”。但短剧不只需要漂亮画面，它还要让观众知道谁在做什么、为什么继续看、镜头之间是不是同一个故事。
有些模型按文字直接生成动态画面，这通常叫文生视频；有些模型从一张静态图出发，让画面产生运动，这通常叫图生视频。文生图则是用文字生成角色或场景的静态画面，常用来先确定视觉方向。知道这几种输入的区别，我才能决定先让模型帮我想象画面，还是让已经选定的画面动起来。
我想把 AI 视频当成一种新的制作能力来研究。我的目标不是先做一部完整短剧，而是先设计其中一个 30 秒开场片段：人物能认出来，动作能看懂，结尾留下一点悬念，让人愿意看下一段。它只用来验证一个开场场景的叙事和制作路线，不代表已经做出一集短剧，也不能单凭它判断连续剧情是否成立。
这里的 30 秒是一个练习规模，不代表行业标准。下面是一套我会采用的制作路线，目的是说明样片怎样规划，不是声称已经完成的短剧实测。

第一步：先有一个能拍出来的故事

短视频时长很短，但不等于故事也可以没有因果。先写出三句话：
  1. 主角想得到什么？
  1. 什么事情挡住了他？
  1. 结尾出现什么变化，让观众想知道接下来会怎样？
例如：一个夜班外卖员把送错的包裹送回去，门后却传来自己的声音。这个设想还不能直接拿去生成视频，但至少有角色、动作和转折。下一步要把它拆成能被观看的镜头，而不是继续往故事里塞更多设定。
我会给每个镜头指定一个功能：交代环境、呈现动作、给出反应、留下信息。30 秒可以先尝试 4 到 6 个镜头，每个镜头只承担一个主要变化。镜头越多，生成、筛选和保持连续性的工作也越多。

第二步：先固定角色，再让角色动起来

如果每个镜头都从文字重新生成，角色的脸、衣服、光线和构图可能会变。文生图适合快速探索人物外观、场景气氛和关键画面，但每张图的变化也可能把它带向不同版本。
我会先做一张角色参考图，写一段简短角色设定：年龄感、发型、服装颜色、随身物件和情绪气质。再做一张主要场景参考图。制作时把这两张图当作固定锚点，不在每个镜头里重新发明人物。
这不是保证角色完全一致的魔法。参考图只是提供稳定的视觉线索，镜头变化、遮挡、表情和模型能力仍会影响结果。我的检查项会包括：脸部特征、衣服关键细节、人物所在位置、主要光线、道具是否突然换样。
以“包裹放到门口，听见声音后回头”为例，我会先把它拆成短镜头，而不是要求一个生成任务同时完成整段表演：
镜头
观众需要看到什么
生成方式的起点
连续性锚点
1
夜晚楼道和主角抵达
场景参考图做图生视频，轻微推进
同一件外套、同一盏冷色楼道灯
2
包裹被放在门边
关键帧转图生视频，动作保持简单
包裹颜色与门牌位置
3
主角听见门后声音
近景或静止画面，声音后期处理
主角站在门的同一侧
4
主角回头，镜头停在表情
图生视频描述动作和镜头运动
面部、衣服和画面方向
5
门内出现异常线索
单独设计一张新关键画面
通过声音或道具接回前一镜头
这张表是分镜草案，不是生成结果。它让我先看见生成任务需要什么素材，也能在某个镜头失败时只重做那一段。
角色参考图的提示词，我会先控制在角色与风格信息上：
我会先选定一张可用参考，再把同一份人物描述带到分镜记录里。若模型支持参考图或角色一致性控制，就同时按其当前功能文档使用；如果不支持，提示词本身无法保证多个镜头稳定一致。

第三步：文生视频和图生视频分工

这两种名字描述的是输入不同。文生视频从文字生成画面，适合探索氛围、补充过场或尝试还没有定型的构想。图生视频则从一张图出发，让它产生运动；当我已经有了构图和角色参考，它更适合继续探索这个画面如何移动。
Runway 对其 Gen-4.5 的官方说明同时列出 Text to Video 与 Image to Video，并建议图生视频提示词重点描述运动，文生视频提示词则同时交代视觉元素和运动。快手发布的可灵 3.0 系列覆盖文本、图像、音频与视频输入输出。具体可用能力、时长与费用会随产品版本变化，我会在真正制作时再查当期说明。
我的选择顺序会是：先确定镜头里必须保留的东西，再决定生成方式。如果环境和角色都还没想清楚，先用文生图或文生视频探索方向；如果我要稳定一个已经选中的画面，就用图生视频尝试动作；如果工具支持参考素材或多模态控制，再按它的当前文档调整输入。

一个图生视频提示词骨架

我会从画面里已经有什么开始，主要写动作和镜头变化：
这个模板不是通用的“咒语”。如果模型把动作顺序理解错，我会把它拆成更短的动作或更少的镜头；如果画面一直改动角色，就退回到单镜头测试，而不是叠加更多形容词。

第四步：剪辑承担故事连续性

模型负责生成镜头，剪辑负责让镜头变成观众读得懂的因果。即使每一段单独看起来不错，拼起来仍可能出现动作跳跃、人物位置不连贯、情绪没有落点的问题。
因此，第一版样片只需要保住三个连接：角色在同一个故事里，动作有前后顺序，结尾回应开头的问题。字幕应该帮助理解，而不是补救完全看不懂的画面。声音、停顿和镜头顺序也会改变观众对同一段素材的理解。
如果我需要生成配音或音乐，会把它们作为独立资产管理，记录素材来源、使用条件和授权状态。画面里出现的真实人物、品牌、影视角色或他人作品，也不因经过生成模型就自动变成没有权利问题的素材。

我会怎样判断第一条片是否完成

我不会用“生成了多少段”衡量这次练习。更实用的是一页检查单：
  • 不看说明，观众能否说出主角在做什么？
  • 镜头之间是否保留关键人物特征和道具？
  • 每段画面是否服务于动作或转折，而不是只做装饰？
  • 失败镜头是靠剪掉解决，还是必须回到提示词重做？
  • 我记录了生成次数、人工挑选和剪辑花费吗？
  • 用到的模型、素材和声音是否能按其现行条件使用？
如果前四项过不了，我会缩小故事，减少角色、场景和动作；如果后两项没有记录，样片就只能证明“画面能生成”，还不能证明这条流程适合持续制作。

我的下一步不是批量生产

AI 视频让我看到的是一种新的分工：文字和图片帮助我明确视觉方向，视频模型探索动态表现，剪辑重新建立叙事顺序，人负责挑选哪些结果值得保留。
文生图、文生视频、图生视频看起来像三个创作按钮，实际需要的是一个连续的制作判断。先让故事足够小，再让角色和镜头有锚点，最后看剪辑能不能把观众带到结尾。
我想先把一条短片做得清楚，再考虑能不能扩大成短剧系列。真正值得复用的不是一段提示词，而是我能解释每一步为什么存在、失败后应该退回哪一步的制作地图。

参考资料

资料核对日期：2026-09-30。本文的 30 秒开场片段为流程示例，需经实际制作后再补充耗时、成本和效果记录。
]]> <![CDATA[AI 做游戏原型怎么起步？把一个点子拆成最小可试玩循环]]> https://www.tangly1024.com/article/ai-game-development-playable-prototype https://www.tangly1024.com/article/ai-game-development-playable-prototype Wed, 30 Sep 2026 00:00:00 GMT
“让 AI 帮我做一款游戏”听起来像一句完整需求，实际上它混合了许多不同工作：设计规则、写代码、画素材、控制操作、处理失败、存档和打包。每一项都能单独做出漂亮演示，但玩家最终面对的是它们拼在一起的体验。
我更想把问题缩小：AI 能不能帮一个人更快把一个玩法点子变成可试玩的原型？这件事值得研究，因为创意有很多，真正能被别人玩到的作品却要经过一连串取舍。
行业工具也在往这个方向前进。Roblox 在 2026 年公开了 Studio agentic 制作方向，Unity 介绍 Unity 7 时也强调 AI 工具参与开发流程。它们说明游戏开发工具正在加入更多 AI 能力，却不能推导出“AI 可以独立做出有趣、完整并且商业成功的游戏”。原型仍然要经过玩家反馈。

游戏的最小单位不是美术，而是一个循环

先想象一个简单画面：玩家控制一只小机器人，在倒计时结束前收集三块能源，同时躲开移动障碍。玩家按键移动，碰到能源就得分，撞上障碍就失去一次机会，时间结束后显示结果并允许重开。
这已经包含一个可讨论的游戏循环：行动、反馈、风险、结果、再来一次。它的图形可以先是色块，声音可以暂时没有；如果玩家连目标都理解不了，再漂亮的角色也不能证明玩法成立。
我会先写一张规则卡：
  • 玩家控制什么，按什么键？
  • 一局里要完成什么？
  • 什么行为会带来奖励？
  • 什么行为会产生代价？
  • 玩家怎么知道自己成功或失败？
  • 为什么愿意再来一局？
这些问题能帮助我把“做个好玩的游戏”变成可以实现、试玩和修改的任务。

我会让 AI 参与哪些工作

玩法变体：让模型围绕同一个核心循环提出几种难度、障碍或奖励机制。我会把它们当作候选，不会一次全塞进原型。每加入一个机制，测试成本也会跟着上升。
代码草稿：把规则卡拆成小任务，例如玩家移动、碰撞判定、计分、倒计时、失败和重新开始。每次让编码 Agent 只完成一段，再直接试玩确认。出现问题时，我需要能定位是规则没说清、代码实现错，还是控制体验本身不好。
我会给编码 Agent 一张短任务卡，而不是请它一口气“做完整游戏”：
每个切片都要有可观察的完成条件。否则 AI 可能把“看起来更像游戏”误当成完成任务，继续添入我还没有验证的功能。
占位素材：使用简单几何形状或明确授权的临时素材建立场景关系。此时素材的任务是让玩家辨认对象，不是追求最终美术风格。原型玩法通过后，再判断哪些角色、背景或音效值得认真制作。
测试清单：让 AI 帮忙列出异常路径，比如贴着边界移动、连续触发碰撞、游戏结束后继续输入、刷新后存档是否丢失。但清单只是提醒，真正的行为要运行和试玩来验证。
这份分工把生成和判断分开。模型可以增加选择空间，玩家与作者一起决定哪些选择值得留下。

一条从点子到试玩的路线

1. 先约束范围

把第一版限制在一个场景、一种主要操作、一个胜利条件和一个失败条件。如果核心玩法需要联网、多角色、复杂背包和长剧情，先把它们放进暂不实现清单。范围小，才知道自己到底在验证什么。

2. 做垂直切片

“垂直切片”指从开局到结束的一小段完整体验。不是先把每个系统都写完，而是先让玩家能够开始、操作、得到反馈、成功或失败，再进入下一局。
这一版不需要完整关卡和最终资产，但至少应该让人看到主要机制。如果用的是熟悉的引擎或网页方案，我会优先利用已有模板和原生功能，减少为了“搭 AI 系统”额外写的基础设施。

3. 尽早找真实玩家

我会先邀请三位没有参与设计的人试玩，并观察他们在哪里停顿、重复按什么键、什么时候不明白目标。三个人只够暴露一些明显问题，不能代表整个市场；但它能比作者自己反复测试更早发现说明不清和反馈不足。每轮可以按下面的格式记，不急着把不同玩家的意见平均成一个分数：
玩家
第一次操作
停顿/误操作位置
是否理解目标
原话/观察事实
我准备改什么
P1
未记录
未记录
待观察
试玩后填写
暂不推断
这是给未来试玩使用的空白记录模板，不代表已进行三位玩家测试。小样本能帮助我定位明显摩擦，不能证明游戏有市场。
我不会只问“你觉得好玩吗”。更具体的问题是：你以为目标是什么？哪一次反馈最清楚？你为什么愿意继续或停止？你有没有遇到意外行为？观察事实和玩家评价都要留在笔记里，不能因为一个夸奖就把项目判定为成立。

4. 决定下一轮投入

原型之后我会做四选一：继续打磨核心循环、调整规则、换掉玩家不理解的部分，或者停止投入。下一轮要解决的是观察到的问题，而不是把功能列表变长。

AI 提速不代表验证可以跳过

当 AI 很快给出一段能运行的代码时，我会更明确地留出检查时间。游戏里看似小的差异，比如碰撞边界、按键延迟、帧率变化、重开状态没清理，都会改变玩家感觉。
我会让 Agent 报告修改了哪些文件、使用了什么假设、有哪些尚未覆盖的情况；然后自己或找玩家验证。对生成的代码、图片、音乐和音效，我也会记录来源与授权条件。能够生成文件，不等于我拥有所有使用和商业化权利。

我的判断：AI 降低了做出原型的门槛，没有替玩家决定是否有趣

AI 游戏开发的价值，不只在于省几个小时写代码。它让一个小团队可以更早尝试玩法、做出可运行的版本，再把时间花到判断上：玩家是否理解、核心循环是否有吸引力、我是否愿意继续维护。
我会把第一目标定为“可试玩”，第二目标才是“好看”，再之后才是扩内容、做发行和商业化。Roblox、Unity 等工具层面的进展值得观察，但每个独立项目仍然要从自己的玩家和目标开始。
一个点子只有在别人手里运行起来，才开始接受现实的检验。AI 可以帮我更快把它送到那一步；游戏是否值得继续，则要由玩法、玩家和我愿意投入的资源共同回答。

参考资料

资料核对日期：2026-09-30。本文为个人原型方法推演，不代表已经完成的游戏测试或市场验证。
]]>