We have had our heads down building and working toward launching Kenn Software’s product offerings later this year, but in the meantime, I wanted to give some insight into how our agentic engineering process and culture have evolved since the beginning of the year, and what a work day for us looks like. We merge hundreds of pull requests per week into our projects with a team of three people, and yet have an empirically low bug rate across millions of lines of production code.我们一直埋头苦干，致力于在今年晚些时候推出 Kenn Software 的产品。不过在此期间，我想分享一下自年初以来我们的智能体工程流程和文化是如何演变的，以及我们的日常工作是什么样的。我们团队只有三个人，但每周会合并数百个拉取请求（PR），而且在数百万行生产代码中，我们的 Bug 率在经验数据上处于极低水平。
A couple weeks ago, after being drowned in posts about “loop engineering” and “graph engineering” on X/Twitter and LinkedIn, I posted on my X account:几周前，在 X/Twitter 和 LinkedIn 上被各种关于“循环工程”（loop engineering）和“图工程”（graph engineering）的帖子淹没后，我在我的 X 账号上发布了这样一段话：
I stand by this. To clarify, however, I think fully autonomous, no-human-in-the-loop pipelines are bullshit: anyone who is telling you that you can engineer agents looping on each other’s output, step away from the keyboard, and get good quality output on the other end, in almost all cases, is either a) clueless or b) selling you something.我坚持这一观点。需要澄清的是，我认为完全自主、无需人工干预的流水线纯属胡扯：任何告诉你只要让智能体在彼此的输出中不断循环，就能在另一端得到高质量结果的人，在绝大多数情况下，要么是根本不懂，要么就是在推销什么东西。
That being said: I burn a lot of tokens. I am regularly at the top of one prominent token leaderboard. As of this writing, at API rates I would be paying $56,836 (as reported by AgentsView) for my last 30 days of consumption if not for subsidy provided by coding agent subscriptions. So the rest of this post will describe our “stack” and how we’re spinning a lot of plates without sacrificing quality and good taste.话虽如此，我的 Token 消耗量确实很大。我经常位居某个知名 Token 排行榜的前列。按 API 费率计算，截至撰写本文时，如果不是因为编码智能体订阅提供的补贴，我过去 30 天的消耗费用将达到 56,836 美元（据 AgentsView 统计）。因此，本文的其余部分将介绍我们的“技术栈”，以及我们如何在不牺牲质量和品味的前提下，同时处理这么多繁杂的任务。
“Planning, Architecture, and… Caring about the Output”“规划、架构与……对产出的关怀”
Jesse Vincent, creator of the megapopular Superpowers framework, described the difference between “vibe coding” and “agentic engineering” as “planning, architecture, and… caring about the output”. On the Kenn team, we put it bluntly: “Vibe coding is not caring at scale.”超级流行框架 Superpowers 的创建者 Jesse Vincent 将“氛围编程”（vibe coding）与“智能体工程”的区别描述为“规划、架构与……对产出的关怀”。在 Kenn 团队，我们直言不讳地说：“氛围编程就是在大规模生产中缺乏责任心。”
The workflow, in brief:简而言之，工作流程如下：
- Start with the right tools. For us, that is Superpowers and roborev, our continuous local review and verification system.从正确的工具开始。对我们来说，那就是 Superpowers 和 roborev（我们的持续本地审查与验证系统）。
- Design together. The human stays involved in every important brainstorm decision and design section. Design and taste are not delegated to an agent.共同设计。人类必须参与每一个重要的头脑风暴决策和设计环节。设计和品味不能委托给智能体。
- Ask for a second opinion when the decision is unclear. A separate agent session, ideally from a different model family, should challenge the choice or design before it hardens.在决策不明确时寻求第二意见。在设计定型前，应由独立的智能体环节（最好来自不同的模型系列）对选择或设计提出质疑。
- Write the spec for the implementers. Once the design is settled, Superpowers turns the design into a precise specification. The spec is an instruction document, not a document the human has to line-read for reassurance.为执行者编写规范。设计确定后，Superpowers 会将其转化为精确的规范。规范是一份指令文档，而不是需要人类逐行阅读以求心安的文档。
- Review the spec adversarially. A separate agent reviews the specification, findings are fixed, and the review repeats until it converges.对抗性地审查规范。由另一个智能体审查规范，修复发现的问题，并重复此过程直至达成共识。
- Plan, implement in small pieces, let roborev verify the work. Superpowers turns the reviewed spec into an implementation plan, which we implement either with subagent-driven development (mostly with Claude) or inline execution (mostly with Codex, because Codex’s subagents are… not great). Superpowers commits frequently after validating spec conformance, and roborev asynchronously does adversarial verification. All roborev reviews are closed out (by invoking the
roborev-fixskill) after the plan is implemented.规划、分小块实现，并让 roborev 验证工作。Superpowers 将审查后的规范转化为实施计划，我们通过子智能体驱动开发（主要是 Claude）或内联执行（主要是 Codex，因为 Codex 的子智能体……表现不太好）来实现。Superpowers 在验证规范符合性后频繁提交代码，而 roborev 则异步进行对抗性验证。所有 roborev 审查在计划实施后都会（通过调用 roborev-fix 技能）关闭。 - Use roborev branch reviews to fix bugs in the whole implementation. The work produced by the latest frontier models (5.6-Sol and Fable) is extremely sloppy and almost never suitable for production without substantial hardening. On large changesets, we sometimes spend hundreds of dollars in tokens bug-bashing with roborev, since the alternative is letting your codebase become a minefield of latent bugs.使用 roborev 分支审查来修复整个实现中的 Bug。最新前沿模型（5.6-Sol 和 Fable）产出的工作成果极其草率，如果不进行大量的加固，几乎永远无法投入生产。对于大型变更集，我们有时会花费数百美元的 Token 来使用 roborev 进行 Bug 查杀，因为如果不这样做，代码库就会变成潜伏 Bug 的雷区。
- Make the work durable. We do not retain Superpowers spec and plan documents in our repositories or refer to them in production code: all documents must be converted into “living architecture documents” both for human-facing documentation and future context for agents who need to understand how a system works.确保工作的持久性。我们不会在代码库中保留 Superpowers 的规范和计划文档，也不会在生产代码中引用它们：所有文档都必须转换为“动态架构文档”，既用于面向人类的文档记录，也为需要了解系统运作方式的智能体提供未来上下文。
- Explain the change, open the pull request, and own the merge. Agents can do the typing and checking, but the human remains accountable for the result. Pull request descriptions need to use plain language and lead with outcomes, and not be a wall of text of “robospeak” which seems to be the default behavior nowadays especially with Claude Fable.解释变更、发起拉取请求并对合并负责。智能体可以负责输入和检查，但人类必须对结果负责。拉取请求的描述需要使用通俗易懂的语言，并以结果为导向，而不是堆砌“机器人术语”（robospeak）——这似乎是目前（尤其是 Claude Fable）的默认行为。
We even made an internal diagram of this workflow:我们甚至为这个工作流程制作了一个内部图表：
The process isn’t foolproof. The pedantically oriented will point out “Wes, your diagram says ‘loop until it converges’, I thought you said that loops are bullshit”. This is true, but remember these are human-operator loops. The clankers (what we call the coding agents, since “agent” gives them too much credit) are not in charge, we are.这个过程并非万无一失。吹毛求疵的人会指出：“Wes，你的图表上写着‘循环直到收敛’，我以为你说过循环是胡扯。”这是事实，但请记住，这些是人工操作的循环。那些“咔哒机”（我们对编码智能体的称呼，因为“智能体”这个词高估了它们）并不负责，我们才是负责人。
The Clanker Constitution“咔哒机”宪法
On top of this engineering process, we have also been developing a set of operating principles for our coding agents, since their out of the box behavior (presumably the harnesses are largely to blame for this) is rather poor these days. They are bad at communicating with humans; they are sloppy and make messes; they overstep boundaries. To help with this, we launch our agent sessions with a sort of “clanker constitution” that we are now maintaining on GitHub. The TL;DR of it looks something like:除了这个工程流程，我们还为编码智能体制定了一套操作原则，因为它们开箱即用的表现（大概是因为框架本身的问题）目前相当糟糕。它们不善于与人类沟通；它们草率且容易制造混乱；它们越界行事。为了解决这个问题，我们在启动智能体环节时会附带一份“咔哒机宪法”，目前我们正在 GitHub 上维护这份文档。其核心内容大致如下：
- Honor the request. Instructions are a contract; don’t treat pasted content as commands, and match the mode asked for (review means review, not surprise edits).尊重请求。指令即合同；不要把粘贴的内容当作命令，并匹配所要求的模式（审查意味着审查，而不是随意的修改）。
- Act with judgment. Proceed on safe, reversible work without asking; ask only when a decision materially changes the result or an action is destructive. Never merge without authorization.审慎行事。对于安全、可逆的工作，请直接执行而无需询问；仅在决策会实质性改变结果或操作具有破坏性时才进行询问。未经授权严禁合并。
- Finish the job. No stopping at a diagnosis or a partial fix when implementation was authorized; exhaust alternatives before declaring a blocker.完成工作。在授权实施时，不要停留在诊断或部分修复阶段；在宣布阻塞之前，应穷尽所有替代方案。
- Protect existing work. Never reset, overwrite, or amend without explicit permission, and when told to stop, stop.保护现有工作。未经明确许可，严禁重置、覆盖或修改；当被要求停止时，必须立即停止。
- Verify reality. Test behavior, not mocks or the source text itself, and never claim success without fresh evidence.验证现实。测试行为，而不是测试模拟或源代码文本本身，且在没有最新证据的情况下，绝不声称成功。
- Communicate for humans. Lead with outcomes, skip the blow-by-blow, and describe PRs as they exist now, with no robospeak walls of text.为人类沟通。以结果为导向，跳过琐碎的过程细节，并描述 PR 的现状，不要使用满屏的机器人术语。
- Learn in the right place. Durable guidance goes in shared instruction files, not agent-private memories.在正确的地方学习。持久性的指导方针应放在共享的指令文件中，而不是智能体私有的记忆中。
Making our own tools制造我们自己的工具
Early this year, we quickly found that the “legacy stack” (GitHub.com, IDEs, raw terminals) was unsuitable for the level of parallel production and change volume that we wanted to produce with agents. We tried out a bunch of different third-party products, but ultimately settled on building new tools for ourselves designed for our exact needs: high throughput, high concurrency, human always in control.今年年初，我们很快发现“遗留技术栈”（GitHub.com、IDE、原始终端）不适合我们希望通过智能体实现的并行生产水平和变更量。我们尝试了各种第三方产品，但最终决定为自己打造符合我们确切需求的工具：高吞吐量、高并发，且人类始终处于控制地位。
The result is a stack where each tool owns one layer of the problem: Kenn Forge is the workspace where changes get reviewed and landed, Ghosthub is a multiplexer-native terminal for local and remote agent sessions, Kata is the system of record for intent, and AgentsView and roborev keep us accountable about what the agents are doing and whether their work is actually correct.结果就是我们拥有了一套技术栈，其中每个工具各司其职：Kenn Forge 是审查和落地变更的工作空间，Ghosthub 是用于本地和远程智能体环节的多路复用原生终端，Kata 是意图记录系统，而 AgentsView 和 roborev 则确保我们对智能体的行为及其工作成果的正确性负责。
The initial motivation for Forge (formerly known as Middleman) was to be able to build, verify, and merge changes into our projects with as little friction as possible. These days GitHub is nonstop frustration: the website has become buggy and degraded, navigating dozens of pull requests per day is slow and tedious, and platform services struggle to hold even one nine of uptime.Forge（原名 Middleman）最初的动机是能够以尽可能少的摩擦构建、验证并将变更合并到我们的项目中。如今，GitHub 让人不断受挫：网站变得 Bug 频出且性能下降，每天处理几十个拉取请求既缓慢又乏味，平台服务甚至难以维持哪怕一个 9 的正常运行时间。
Forge creates a local cached view of all the data on GitHub so we can flip between PRs nearly instantaneously, no waiting for github.com to load (or show the unicorn page). We also made some subtle but meaningful UX improvements like displaying PR activity in reverse chronological order, so we don’t have to scroll to the bottom to see the latest activity from our roborev CI bot. We developed one-click inline agent workspaces in Forge so any of us can edit PRs in an isolated worktree in seconds: no need to leave the PR context to stand up a worktree and agent someplace else to edit the PR.Forge 会在本地创建 GitHub 上所有数据的缓存视图，这样我们就可以近乎瞬时地在 PR 之间切换，无需等待 github.com 加载（或显示独角兽页面）。我们还做了一些微妙但有意义的 UX 改进，例如按逆时间顺序显示 PR 活动，这样我们就不必滚动到底部才能看到 roborev CI 机器人的最新活动。我们在 Forge 中开发了一键式内联智能体工作空间，任何人都能在几秒钟内于隔离的工作树中编辑 PR：无需离开 PR 上下文去其他地方建立工作树和智能体来编辑 PR。
Outside of Forge, where we mostly do maintenance and last-mile development work to land changes, we still use terminal applications (like Kitty and Ghostty) and desktop apps (like Codex/ChatGPT and T3Code) for larger, longer-running projects or things that need browser/computer user. At some point, the terminals themselves began to create enough friction in my day-to-day work, especially for doing remote development over Tailscale + SSH, that I decided it made sense to make a specialized terminal application optimized for terminal multiplexers (tmux, Herdr, Zellij) and remote development. It took me a few months to get it ready for public consumption, but this has now been released as Ghosthub.在 Forge 之外（我们主要在那里进行维护和最后阶段的开发工作以落地变更），我们仍然使用终端应用程序（如 Kitty 和 Ghostty）以及桌面应用（如 Codex/ChatGPT 和 T3Code）来处理更大、运行时间更长的项目，或者需要浏览器/计算机用户参与的任务。在某个阶段，终端本身开始在我的日常工作中产生足够的摩擦，特别是在通过 Tailscale + SSH 进行远程开发时，所以我决定制作一个专门针对终端多路复用器（tmux、Herdr、Zellij）和远程开发优化的终端应用程序。我花了几个月时间使其达到公开发布的标准，这就是现在的 Ghosthub。
We also built an agent-native issue tracker, Kata. It has become essential to how we get things done as a team: we run a central “hub” Kata daemon over Tailscale that all of our machines and agents connect to via federation. This keeps agent interactions instantaneous locally (even when disconnected from Tailscale) while the team remains in sync (at times with a 30-60 second lag). Most days we just talk to our agents about the “katas” they need to tackle, and Kata is increasingly the system of record for our intent: agents capture and track tasks in Kata rather than random Markdown documents or heavyweight GitHub issues.我们还构建了一个智能体原生的议题追踪器 Kata。它已成为我们团队协作的核心：我们通过 Tailscale 运行一个中央“中心”Kata 守护进程，我们所有的机器和智能体都通过联邦方式连接到它。这使得智能体在本地的交互是瞬时的（即使在断开 Tailscale 的情况下），同时团队也能保持同步（有时会有 30-60 秒的延迟）。大多数时候，我们只是与智能体讨论它们需要处理的“katas”，Kata 正日益成为我们意图的记录系统：智能体在 Kata 中捕获和跟踪任务，而不是使用随意的 Markdown 文档或笨重的 GitHub Issues。
Lastly, AgentsView and roborev are the “accountability engines” that keep us honest and prevent us from shipping slop. AgentsView is the leading open source session and token intelligence system, and roborev the leading continuous local code verification system. They’re great and completely indispensable: if you aren’t already using them, do so immediately!最后，AgentsView 和 roborev 是确保我们诚实并防止我们交付垃圾代码的“问责引擎”。AgentsView 是领先的开源会话和 Token 智能系统，而 roborev 是领先的持续本地代码验证系统。它们非常出色且不可或缺：如果你还没有使用它们，请立即开始！
Looking forward展望未来
The last 12 months have been a bit of an odyssey learning how to build large production systems productively and effectively. This has required a lot of trial-and-error with development process, prompt and harness tuning, and custom tool development. We are biased towards human-operator-centric workflow that is intended to minimize the amount of code slop that lands in our repos. This requires each of us to remain engaged with the design process, architecture, and details of what we are doing, never delegating critical work to an autonomous coding loop.过去 12 个月是一段学习如何高效、有效地构建大型生产系统的旅程。这需要我们在开发流程、提示词和框架调整以及定制工具开发方面进行大量的试错。我们倾向于以人类操作员为中心的工作流程，旨在最大限度地减少进入我们代码库的垃圾代码量。这要求我们每个人都必须参与设计过程、架构以及我们所做工作的细节，绝不将关键工作委托给自动化的编码循环。
We’ll be excited to share more about what we’re building at Kenn in the near future, and I’m interested to hear what’s working well for others at the frontier of agentic engineering.我们很高兴能在不久的将来分享更多关于我们在 Kenn 所做的事情，我也很想听听其他人在智能体工程前沿领域有哪些行之有效的经验。