Skill、Agent、AI Client 与 Multica：AI 工作流的四层边界

最近我在整理自己的 AI 工作流。Daily brief、Session 分析、代码交付检查、内容生产、知识整理，这些工作都在逐渐用上 Skill 和 Agent。但流程多了以后，有个问题需要理清楚：哪些工作直接在 AI Client 里做就够了，哪些值得交给固定的 Agent，哪些又需要放进 Multica 管理？

我之前考虑过把更多流程搬进 Multica。不过，写文章、讨论方案、调试代码时，我经常需要边看结果边调整要求，直接在客户端里调用 Skill 更方便。另一些任务需要反复运行，或者交给其他人一起处理，关注点就变成了执行状态、失败处理和交接。

要判断任务放在哪里，先得把 Skill、Agent、AI Client 和 Multica 各自负责的事情说清楚。这里的“四层”是我安排工作的职责划分，同一个任务可以同时用到它们。

Skill：把做事的方法留下来

Skill 适合保存一类任务可以复用的方法，包括输入要求、处理步骤、约束、需要使用的工具、输出格式和验收标准。下次再做类似的事情，就不用从头解释一遍。

以写博客为例，写作 Skill 可以规定从哪些材料开始、怎样区分事实和个人判断、哪些表达需要改掉，以及交稿前检查什么。它保存的是写作要求。具体写哪篇文章、这次有哪些材料、最后是否接受稿子，仍然要在任务里确定。

把 Skill 理解成 SOP 比较容易上手，不过不必把所有 Skill 都写成严格的步骤清单。有的主要提供判断标准，有的还带着脚本、模板和参考资料。只写一句“请帮我把文章写好”，这些要求并没有被记录下来。

我希望保存在 Skill 里的方法能被不同 Agent 复用。至于换一个客户端后能否直接执行，还要看工具和环境是否支持，不能只看有没有复制过去一份文件。

Agent：给任务一个明确的执行者

Agent 可以围绕一个目标，使用相应的工具和 Skill 执行任务。这里我主要关心的是：有没有必要为一类工作保留一个职责稳定的执行角色。

例如 Code Review Agent 可以组合安全检查、架构检查和代码规范相关的 Skill，负责找出代码风险并给出审查意见。这时还需要说清楚它检查什么、能访问哪些材料、是否允许修改代码，以及什么情况下应该停止并交回给人。只给它起一个“代码审查专家”的名字，职责并不会自动清楚。

Skill 和 Agent 因而可以分开维护。审查方法变了，就修改相应的 Skill；执行角色的范围变了，再调整 Agent 的职责。一个 Agent 可以使用多个 Skill，同一个 Skill 也可以被不同角色调用。

对我来说，重复任务、有固定目标和明确输入输出的工作，更值得配置这样的 Agent，比如财报分析、内容审核和代码审查。但这并不表示 Skill 做大以后就必须“升级”为 Agent。方法仍然需要保留，Agent 负责在具体任务中使用它。

AI Client：我直接参与工作的入口

我在这里说的 AI Client，是 Codex、Claude Code、OpenCode 这类直接与 AI 交互的客户端。讨论问题、查看文件、修改代码、执行命令和检查结果，都是通过这个入口进行的。

新功能开发和架构设计尤其需要这种交互。需求往往还没有完全确定，我要先看方案为什么这样设计，再决定接受、修改，还是换个方向。随着讨论推进，也可能需要重新调整问题。在同一个工作上下文里处理这些变化，比提前规定好整条流程更适合这类任务。

临时研究、调试、学习、Prompt 设计和开发新的 Skill，也可以先在客户端里完成。需要复用的方法就调用已有 Skill，需要临时分工时再交给相应的 Agent。

这里强调的是我使用客户端时的交互方式，不能据此把 AI Client 和 Agent 当成二选一。客户端里也可以有 Agent 执行任务；“我是否持续参与”和“谁负责执行”是两个不同的问题。

Multica：管理交出去的工作

我考虑放进 Multica 的，是那些交出去以后仍然需要管理的任务。例如每天运行的分析、外部事件触发的检查，或者需要多人查看和接手的工作。

这类任务要解决的问题比较具体：任务现在进行到哪一步，谁负责处理，失败了是否重试，需要人工判断时交给谁，以及下一位参与者从哪里继续。选平台时，我会检查这些需求能否得到支持。仅仅能够调用 Skill，还不足以说明值得把流程搬进去。

多角色协作也一样。需求分析、开发、测试和 Review 可以分给不同 Agent，但把几个名字用箭头连起来，交接就算完成了吗？前一个角色要留下什么材料，后一个角色凭什么开始，意见冲突由谁处理，都需要提前明确。

所以我不会只因为任务复杂就创建 Squad。研究、写作、审核和发布，如果各自有稳定的职责、不同的工具或权限要求，可以考虑拆开。只按标题、摘要、正文把一篇文章拆给三个 Agent，则要先说明这种拆分能带来什么收益；它们需要保持一致，拆开以后还得重新协调。

这些是我考虑使用 Multica 的条件。具体迁入某项任务时，还需要验证执行、交接和失败处理是否符合预期。

具体任务怎么选

前面四者可以组合使用，选择时我会分别考虑方法复用、执行职责、交互方式和运行管理，不按任务名称直接归类。

写文章和内容生产。 写作规范放进 Skill。单篇文章需要反复讨论观点、改措辞、确认稿子时，在 AI Client 里完成比较合适。如果长期有一批相似的内容审核任务，可以配置职责固定的内容审核 Agent。进一步涉及排期、多人交接和发布审批，再考虑用 Multica 管理整个流程。拆成 Content Squad 的理由应当是实际分工需要。

软件开发和代码检查。 新功能开发、调试和重构，我仍然倾向于在客户端里边做边看。个人检查可以直接调用 Review Skill；如果要持续承担某类审查职责，可以配置 Review Agent。团队统一收集审查任务、跟踪处理状态或安排交接时，才增加平台管理。个人和团队场景的区别，需要落实到这些操作上。

投资研究。 学习和临时研究需要随时追问，适合直接交互；分析方法可以写成 Skill，供不同研究任务复用。每日分析若有稳定的输入输出，可以交给固定 Agent。需要定时触发和跟踪结果，再加入平台。多专家研究是否值得拆成 Squad，要看各角色能否提供不同的分析，以及最后如何处理分歧，不能只看专家数量。

Daily brief、Session 分析和知识整理。 临时整理一批材料，客户端配合 Skill 通常就够了。如果变成持续收集、定期处理、多人查看结果的工作，就需要进一步明确 Agent 的职责和平台的管理要求。任务名字没有变，运行方式变了，使用的组合也可以变。

具体迁移一项任务之前，我还会比较一下：这次增加平台，究竟省掉了哪项人工操作，又多了哪些需要维护的流程。如果这些还说不清楚，可以先维持现有的做法。