Penguin 是一个可组合的工作流构建工具，让你完全掌控自己的自动化流程，而不受任何平台或框架预设工作流的限制。
设计哲学
Penguin 的设计体现了以下理念：
- 你掌控工作流 — 不依赖任何平台预设的流程
- 代码优于自然语言 — 复杂逻辑用 TypeScript 表达更清晰
- 确定性的用脚本，不确定的用 Agent — 不滥用 Agent 调用
- 持久运行 — 关闭终端不影响工作流执行
- 响应多种触发器 — Slack、GitHub、Jira、Webhook，任何你能构建适配器的地方
谁规定你的代码工厂必须听别人的！
打工人的代码流水线，凭什么让别人替你画图纸？
当Vercel、Linear、Anthropic和OpenAI们争先恐后地把你的开发流程塞进他们预设的模版时，有一个人拍桌子说不。他用TypeScript写了一个叫Penguin的工具，核心就一句话：你的工作流，你说了算。这件事的反常识之处在于，整个行业都在拼命把开发者塞进更智能的笼子，而他却把笼子的钥匙递回给你。
2026年8月，一个名叫Mikael Weiss的开发者把Penguin 0.0.1版扔上了npm。这个工具目前还挂着beta标签，但作者已经拿它在自己的工作里跑通了从ticket到PR的全流程，甚至用Penguin来写Penguin自己。一个工具如果连自己都造不出来，凭什么让别人信。Penguin的体量小得惊人，安装包只有九个工作流、四个适配器和一个tsconfig配置文件。但就是这九个文件，正在撬动一个被巨头们垄断的叙事：你的开发流程到底该由谁来设计。
预设工作流才是最大的笑话
你打开Vercel的部署界面，点几下按钮，代码就上了线。你打开Linear的看板，拖一张卡片，任务就流转到了下一个阶段。你觉得方便。但你有没有想过，这些方便是谁替你定义的。
Vercel替你定义了从push到production的路径。Linear替你定义了从backlog到done的节奏。Anthropic和OpenAI替你定义了Agent该在什么时候介入、该用什么方式思考。你只是在一个被设计好的迷宫里走路，迷宫的墙纸很好看，但迷宫始终是迷宫。
Penguin说，去你的迷宫。它的核心原语只有三个：Workflows（工作流）、Adapters（适配器）、Messages（消息）。工作流就是一段TypeScript代码，带一个参数校验和一个run函数。适配器是连接外部的桥，GitHub、Jira、Slack，或者你随便写一个。消息是这些部件之间传递的信号，异步也行，同步也行。就这三个东西，够你拼出任何你想要的流程。
这就怪了。整个行业都在把工作流封装成黑盒，一键部署、一键发布、一键搞定一切，Penguin偏偏把一切都摊开给你看。你不需要在别人的UI里点来点去，你写代码。代码就是你的图纸。你画成什么样，流水线就长什么样。
你永远分不清Agent是干完了还是在等你
用过Copilot或者Claude Code的人都有过这种体验：Agent停下来了，你不知道它是把活干完了，还是卡住了在等你点头。你盯着终端发呆，等了三分钟，它突然冒出一句“请确认是否继续”。你血压上来了。
这个问题看起来小，但它是整个Agent工作流里最折磨人的地方。你不敢走开，因为你不知道它什么时候会问你。你不敢一直盯着，因为你还有别的事。于是你就被钉在椅子上，扮演一个人肉监控摄像头。
Penguin解决这个问题的办法粗暴但有效：它把“Agent完成”和“需要人工输入”彻底切开了。工作流里可以写一个叫gate的东西，就是一个确定性的暂停点。比如“Slack来了一条新消息，你要不要暂停实现先去回复”。Agent停下来了，原因只有两种：要么它真的做完了，要么它在gate等你。没有第三种模糊地带。
事情没那么简单。这个设计背后藏着一个更深的判断：你不应该让Agent来决定什么时候需要人。人应该在流程里预先画好需要自己的位置，而不是被动等待Agent的召唤。换句话说，Penguin不信任Agent的判断力，它信任的是你对流程的控制力。这跟当前主流Agent框架的思路完全相反。主流框架拼命让Agent变得更聪明、更会判断什么时候该问人，Penguin说别费那劲了，人自己定。
自然语言不适合搭积木
你要是用过那些用自然语言配置工作流的工具，你一定经历过这种事：你想让工作流A跑完以后同时启动工作流B和C，等B和C都跑完了再启动D。用自然语言描述这个逻辑，你得写一大段啰嗦的指令，而且模型还经常理解错。
代码就干净得多。TypeScript里写await Promise.all([workflowB(), workflowC()])，然后await workflowD()。三行搞定，没有歧义，不需要猜模型有没有听懂。
Penguin把工作流写成TypeScript文件这件事，看起来只是个技术选择，实际上是一个哲学判断：代码比自然语言更适合描述逻辑。自然语言的优势是灵活，但灵活的反面是模糊。当你需要精确控制流程的分支、并行、阻塞、超时、重试时，代码的精确性是不可替代的。
而且Penguin的工作流是可以互相调用的。一个工作流像普通函数一样import另一个工作流，传参、执行、拿结果。这就意味着你可以把复杂流程拆成小块，每一块单独测试、单独迭代，然后再组合成更大的流程。这才是真正的可组合性。不是拖拽几个方块连几条线，而是像写程序一样写流程。
MCP和CLI被用在了不该用的地方
现在做AI编程工具的人，有一个默认动作：遇到任何需要外部数据的事，就让Agent去调MCP（Model Context Protocol）或者执行CLI命令。要读GitHub issue，让Agent调GitHub MCP。要创建Jira工单，让Agent调Jira MCP。要review PR，让Agent调PR MCP。
这个做法看起来自动化程度很高，但实际上有一个巨大的成本：每次调用都是一次LLM推理，都要花钱、花时间、冒出错的风险。而读一个GitHub issue的内容，本质上是调用一个REST API，然后把JSON解析出来。这件事完全不需要AI的参与。
Penguin的做法是：把这些确定性的事情写成脚本，直接在工作流里调用。需要读ticket，直接调用Jira适配器。需要开PR，直接调用GitHub适配器。Agent只负责那些真正需要推理的部分，比如“这个ticket描述的需求该怎么拆分成任务”或者“这段代码的实现方案有什么问题”。
这个区分看起来简单，但它是Penguin整个设计里最反常识的一点。当前行业的主流叙事是让Agent做越来越多的事，最好从头到尾全是Agent在跑。Penguin说不行，Agent应该被限制在它擅长的领域里，其他事情交给确定性代码。这就好比让一个数学家去算1+1，不是算不对，是太浪费了。
你可以完全不叫Agent
Penguin最狠的一点藏在最后：你可以构建一个包含步骤、阻塞器、完整逻辑的工作流，从头到尾不调用任何Agent。
这句话乍看没什么，细想一下脊背发凉。这意味着Penguin先把工作流引擎本身做好了，Agent只是这个引擎可以挂载的一个插件。跟市面上的Agent框架完全是反过来的。别人是先有Agent，然后在Agent外面包一层工作流的壳。Penguin是先有工作流引擎，Agent只是一个可选的处理器。
这个顺序的区别太大了。前者让你永远被困在Agent的思维框架里，所有流程设计都要围着Agent的能力转。后者让你先想清楚流程本身长什么样，然后再决定哪些步骤需要AI介入、哪些步骤不需要。
作者在Claude Code的GitHub issue里留过一句话，说他想要“Sonnet 4.5做规划、Haiku做执行”。这个细节暴露了他的思维方式：不同环节用不同模型，不同任务用不同工具，一切都是可替换的、可优化的。没有哪个模型是神圣不可替代的，没有哪个工具是必须绑定的。
一个用TypeScript写成的反叛
Penguin的安装命令是npm install -g @mikaelweiss/penguin，需要Node 24或更新版本。第一次运行会在~/.penguin/目录下创建starter catalog，包含九个开箱即用的工作流。其中两个是流水线：pn run ticket --ticket ABC-123从triage到plan到worktree到implement到PR全程自动化；pn run fix --bug "..."复现bug、修bug、跑本地检查、开PR。另外七个是小组件：triage判断ticket是否就绪、plan生成计划和验收标准、implement在当前仓库实现变更、review做一次审查、verify跑仓库检查、pr开PR并循环处理反馈、review-pr拉取PR diff做审查。
每个工作流都是一个独立进程，关掉终端它还在跑。终端只是一个viewer，attach上去看进度、发消息、detach走人。这个设计保证了你可以把长流程扔在后台，不用守着终端干等。
适配器方面，开箱自带claude（Agent接口）、git、gh（GitHub CLI）和terminal。凭证存在~/.local/state/penguin/credentials/，权限0600，安全级别拉满。
但最让人在意的是这件事：作者说他已经开始在工作和构建Penguin本身时使用Penguin了。一个工具用它自己来构建自己，这在软件工程里叫自举（bootstrapping）。能做到自举的工具，通常意味着它的抽象已经足够完备，能够描述它自身的构建过程。
被忽视的悖论
Penguin目前还挂着beta标签，GitHub上星星不多，npm下载量也还在爬坡阶段。但它的存在本身已经构成了一个悖论：那些最擅长帮别人搭建工作流的平台（Vercel、Linear、Anthropic、OpenAI），恰恰是限制你选择工作流自由的最大力量。他们给你提供了漂亮的界面、流畅的体验、一键部署的快感，但代价是你只能在他们的轨道上跑。
Penguin选择了一条更难的路。它不给你界面，不给你一键部署，不给你任何开箱即用的漂亮体验。它给你的是三个原语和一堆TypeScript文件。你得自己写代码来定义你的流程，自己画你的图纸。
这就引出了一个没法绕过去的问题：如果一个工具把全部控制权都交给你，但同时也把全部复杂度都交给你，你到底是获得了自由，还是换了一种方式被奴役。
Penguin的README里没有回答这个问题。作者可能也没想好答案。他用Penguin在工作里跑通了流程，也用Penguin构建了Penguin本身，但他没说这套东西对普通开发者来说门槛到底有多高。一个需要你写TypeScript来定义工作流的工具，跟一个让你点几下鼠标就能配置流程的平台，中间隔着的不是一个技术选型，是一整个认知层级。
Beta标签还挂在那里。事情还没完。