Keyoku - 把代理操作记录变成可复用 MCP 工作流
现在用 coding agent 做开发时，一个常见的摩擦点不是“模型会不会写代码”，而是同一类项目流程会被反复口头描述：怎么跑检查、怎么收集上下文、怎么整理变更、什么时候需要人工确认。对个人来说，这些流程散落在记忆里；对团队来说，它们又很难直接沉淀成 agent 能调用的操作。
今天推荐的 Keyoku-ai/keyoku 就是针对这个问题的小工具。它是一个 TypeScript 写的 CLI / MCP server，定位是给 Claude Code、Cursor 和 Codex 做本地活动追踪、模式发现和工作流执行。项目 README 把它描述为会观察你的代理操作，学习重复模式，然后把它们变成一条命令可运行的 MCP-native workflow。
发布时 GitHub 搜索结果显示项目约 20 stars、5 forks，主要语言是 TypeScript，许可为 MIT，创建于 2026-03-10，最近仍在更新。仓库 tag 和 npm registry 都显示当前包版本为 2.0.2。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | Keyoku-ai/keyoku |
| 定位 | 本地活动追踪、工作流发现与 MCP 执行层 |
| Stars | 约 20 |
| Forks | 5 |
| 主要语言 | TypeScript |
| 许可 | MIT |
| 当前版本 | 2.0.2 |
它记录的是过程，不只是结果
很多 agent 辅助开发工具会重点放在上下文检索或代码生成上。Keyoku 的切入点更像是“过程层”：它通过 hooks 记录代理工具调用，比如 Bash、Edit、Write、Read、MCP call，并把这些调用保存成轻量的 activity event。默认状态目录是 ~/.keyoku，README 强调没有云端和 telemetry，记录、模板和执行历史都在本地。
这个思路适合那些很难写成静态文档、但又会反复出现的工作。比如每次修同一个仓库都要先跑一组检查、读取某些约定文件、生成变更摘要、等待人工确认后再执行部署。一次两次可以靠提示词，重复多了就应该变成可审计的流程。
Keyoku 的目标不是让 agent 直接自动化一切，而是把“我刚刚是怎么做的”转成可以回放、可以审查的模板。这个边界很重要，因为开发流程里有些步骤适合 shell 直接跑，有些步骤需要 agent 判断，还有些步骤必须停下来等人看。
从历史会话里挖出重复流程
安装方式很直接：
npm install -g keyoku
keyoku initkeyoku init 会把 MCP server 注册给 Claude Code，也会在检测到 ~/.codex 时写入 Codex 的 config.toml。README 还提到，可以通过 keyoku import 从 Claude Code 和 Codex 的历史 transcript 里回填活动记录，减少刚安装时没有样本的冷启动问题。
工作流发现由 workflow_suggest 触发。Keyoku 先用启发式规则从近期 activity 里找重复序列，例如非重叠计数、降噪和最长链折叠；如果配置了 GEMINI_API_KEY 或 ANTHROPIC_API_KEY，它还可以用小模型对候选工作流做二次整理：过滤巧合、命名流程，并把每次运行都会变化的值参数化成 {{placeholders}}。
这套设计的好处是成本边界清楚。基础发现不依赖模型，模型只参与“把草稿整理得更像可维护模板”的环节。真正的大任务仍然交给你日常使用的 coding agent。
审批是信任边界
Keyoku 不是把发现到的序列直接变成自动化脚本。README 里反复强调 approval：候选 workflow 需要通过 workflow_approve 保存，模板会进入 ~/.keyoku/templates.json。你应该像审 shell script 一样审这些步骤。
执行时，模板里的步骤有不同类型：
bash：按指定cwd和 timeout 执行命令，并记录输出。agent_prompt：暂停执行，把这一步交给 coding agent 判断，之后通过execution_complete继续。human_review：明确等待人工确认。
这比单纯生成 shell 脚本更适合 agent 工作。很多开发流程不应该被压扁成一串命令：测试失败后的判断、代码审查后的取舍、部署前的最终确认，都需要保留不同的控制点。
MCP 工具覆盖模板、知识和目标
Keyoku 暴露了一组 MCP tools。核心是活动记录和 workflow 管理：activity_record / activity_list、workflow_suggest、workflow_capture、workflow_approve、workflow_execute、execution_list 等。
除此之外，它还带了 knowledge_submit / knowledge_query 这样的上下文层，以及 goal_create / goal_assess 这类目标检查工具。README 还提到 connector 相关工具，可以接入外部 MCP server，并通过 autonomy gating 控制调用。
这让 Keyoku 更像一个本地 agent workflow runtime，而不是简单的命令历史工具。它关心的不只是“跑过哪些命令”，还包括哪些经验可以沉淀成知识，哪些目标有可检查的成功标准，哪些外部调用需要审批。
和 Codex / Claude Code 的位置关系
我觉得 Keyoku 最有意思的地方，是它不试图替代 Codex、Claude Code 或 Cursor。它更像这些工具旁边的一层本地记忆和流程外壳：记录代理怎么操作，发现可以复用的套路，然后以 MCP 工具的形式再交还给代理调用。
这对多项目工作尤其有用。不同仓库有不同的测试命令、部署命令、审查习惯和上下文文件。与其每次都在提示词里重新描述，不如让一部分流程被活动记录捕捉、审批成模板，并在下次由 agent 主动建议。
当然，它也带来新的安全面。模板里的 bash 步骤会以你的权限执行；外部 connector 也可能触达真实服务。Keyoku 的审批模型能提供边界，但不能代替你审查模板内容。安装前应该读一遍仓库里的 SECURITY.md，并先在低风险仓库里试用。
小结
Keyoku-ai/keyoku 是一个很早期但方向明确的开发者工具：它把 coding agent 的本地操作记录下来，从重复流程中挖出 workflow，再通过 MCP 暴露为可审批、可执行的模板。
如果你已经在 Claude Code、Cursor 或 Codex 里反复做同一类项目流程，Keyoku 值得关注。它不解决代码生成本身的问题，而是解决“流程如何从一次性提示词变成可复用操作资产”的问题。对长期维护多个仓库的人来说，这个层次可能比又一个提示词片段更有价值。