Multica Autopilot
Multica Autopilot 的核心价值，不是又多了一个 chat app，而是它把 Routines 这类重复性 agent 工作流，从单一产品能力抽象成了一个跨 agent、可本地运行的执行层。
核心论点
如果一个工作流会重复发生，那么它不应该只活在某个聊天窗口里，而应该被固化成可调度、可替换 agent、可追踪状态的 routine。
今天的信号
2026-04-15 的推文和仓库信息共同说明了两个方向：
- 推文层：Multica 团队把 Claude Code 的 Routines 思路做成了开源版本，可在本地运行，并支持 Opencode、Codex、Hermes、OpenClaw
- 仓库层：Multica 把自己的定位写成 managed agents platform，目标是把 coding agents 变成 teammates，而不是临时助手
为什么重要
这意味着 agent 工作流开始从“prompt 工具”走向“任务系统”：
- 任务可以像分派给同事一样被指派
- 运行状态可以持续跟踪
- 阻塞可以被上报
- 经验与技能可以累积，而不是每次重讲
这和 把 Skills 接进 Loops、Harness 即记忆 是一条线上的进展。
和普通聊天式 agent 的差异
| 维度 | 聊天式 agent | Multica Autopilot 这类 routine 层 |
|---|---|---|
| 入口 | 临时 prompt | 预定义任务 |
| 状态 | 对话内短期状态 | 可追踪任务状态 |
| 可迁移性 | 强依赖单个产品 | 可切换不同 agent |
| 复利 | 主要靠人复用 prompt | 靠 routine + 状态 + 技能积累 |
对我们有用的启发
- 高频重复任务不要只保存在聊天记录里
- 设计 routine 时应抽象输入、验证、输出，而不是绑死在某个模型上
- 如果一个 agent 需要反复 babysit，说明它还没有变成真正的 routine
Counterpoints & Gaps
- 现在最清楚的是调度层价值，但多用户权限、审计、失败恢复还需要更多真实案例
- agent-agnostic 很有吸引力，但不同 agent 的行为差异仍会增加 routine 设计成本
- 本地运行降低了门槛，也意味着团队协作、共享状态、统一观察面会变成下一问题
关联页面
- harness-engineering/skills-into-loops
- harness-engineering/your-harness-your-memory
- harness-engineering/lightweight-vs-orchestration-harness
- Desktop Redesign