(This blog post is derived from this video on my YouTube channel, along with a short follow-up about the incentives involved.)（本篇博文源自我 YouTube 频道上的这段视频，以及随后关于其中激励机制的简短补充。）

I’ve been writing about specialized agent harnesses and compiling them from task specifications for a while, and I realize the idea can sound abstract. So here’s a concrete example from a workflow I run every day.我一直在撰写关于专用代理工具（agent harnesses）的文章，并尝试根据任务规范对它们进行编译。我意识到这个概念听起来可能比较抽象，所以这里提供一个我每天都在运行的工作流中的具体示例。

I have a skill that looks through my back catalog of blog posts, finds something worth resurfacing, checks whether I’ve mentioned it recently, and drafts a short LinkedIn post linking back to it. The draft never gets posted automatically. Often I don’t post it at all. Sometimes I use it as a nudge and rewrite the whole thing in my own voice. But the workflow is useful: it nudges me to repost existing writing.我有一个技能，它会浏览我过往的博文目录，找出值得重新发布的内容，检查我最近是否提到过它，并草拟一篇简短的 LinkedIn 帖子进行链接。这个草稿从不会自动发布。通常我根本不会发布它，有时我会把它当作一个提醒，然后用我自己的口吻重写整个内容。但这个工作流非常有用：它提醒我重新发布已有的文章。

The original version was written entirely as natural-language instructions in an Agent Skill. It described the sources to search, the recent-history checks, the selection criteria, and the shape of the final draft. On every run, my agent (currently Codex) had to interpret those instructions, make a plan, call tools, and keep track of the state of the workflow.最初的版本完全是以自然语言指令的形式写在“代理技能”（Agent Skill）中的。它描述了要搜索的来源、近期历史检查、筛选标准以及最终草稿的格式。每次运行，我的代理（目前是 Codex）都必须解读这些指令、制定计划、调用工具并跟踪工作流的状态。

That was a great way to build the first version. Natural language made the workflow easy to articulate and change. I’ve written before about these files as natlang code: executable SOPs that let an agent automate work without first turning every judgment into a conventional program.对于构建第一个版本来说，这是一种很棒的方法。自然语言使得工作流易于表达和修改。我之前写过关于这些文件作为“自然语言代码”（natlang code）的文章：它们是可执行的 SOP（标准作业程序），让代理无需将每一个判断都转化为传统程序，就能实现工作自动化。

But after a skill has run many times, and trodden the same ground repeatedly, often most of its behavior is no longer exploratory.但当一个技能运行多次并反复踏足同一领域后，其大部分行为往往不再具有探索性。

The workflow had crystallized工作流已经“结晶化”了

This skill always looks in the same places. It builds the same content inventory. It applies the same recent-post filters. It saves the same intermediate state. None of that needs to be reasoned through from scratch each morning. A lot of it doesn’t even need an LLM!这个技能总是查看相同的地方，构建相同的内容清单，应用相同的近期帖子过滤器，并保存相同的中间状态。这些都不需要每天从头开始推理。其中很多甚至根本不需要大语言模型！

There are really only two steps where LLMs are needed:实际上，只有两个步骤需要用到大语言模型：

  1. Choosing a good candidate from the filtered inventory.从过滤后的清单中选择一个合适的候选内容。
  2. Writing the LinkedIn draft.撰写 LinkedIn 草稿。

Everything else can be ordinary deterministic code.其他所有步骤都可以是普通的确定性代码。

So I “compiled” the skill into a specialized harness. The new skill is barely a skill at all—it has become a thin bootloader that invokes a Python program. That program fetches the known sources, constructs the inventory, checks recent posts, applies filters, and manages the workflow. It calls an LLM only for selection and generation.因此，我将该技能“编译”成了一个专用工具。这个新技能几乎算不上是一个技能了——它变成了一个调用 Python 程序的精简引导程序。该程序负责获取已知来源、构建清单、检查近期帖子、应用过滤器并管理工作流。它仅在选择和生成内容时才调用大语言模型。

Not surprisingly, this resulted in massive token usage and latency improvements:不出所料，这带来了巨大的 Token 使用量和延迟方面的改善：

  • 94% fewer tokensToken 使用量减少了 94%
  • 87% lower latency延迟降低了 87%
  • essentially the same output quality in my runs在我的运行中，输出质量基本保持不变

I didn’t get those gains by swapping in a smaller or cheaper model. The selection and generation steps still use the same model. The savings come from removing all the model calls that were doing work regular code could do more directly.我并非通过更换更小或更便宜的模型来获得这些收益。选择和生成步骤仍然使用相同的模型。节省下来的部分来自于移除了所有那些本可以用常规代码更直接地完成工作的模型调用。

A general-purpose coding agent is an extraordinarily capable reasoning and workflow engine. It’s also an expensive way to execute a procedure whose shape becomes known after introspecting on a few historical invocations.通用编程代理是一个非常强大的推理和工作流引擎。但如果一个流程在经过几次历史调用后，其形态已经变得明确，那么继续用这种方式执行它就显得过于昂贵了。

What “compiling” means here这里所说的“编译”意味着什么

I had historical traces from running the skill previously (it was running daily as an automation in Codex). Those traces showed what the agent actually did, including the planning, tool calls, branching, and state it needed along the way. I gave those traces, the original skill, and my writing about specialized harnesses to a powerful model. I asked it to identify which steps genuinely required an LLM and which had become stable enough to express as code, then build the specialized harness.我保留了该技能之前运行的历史轨迹（它作为 Codex 的自动化任务每天都在运行）。这些轨迹显示了代理实际执行的操作，包括规划、工具调用、分支以及过程中所需的状态。我将这些轨迹、原始技能以及我关于专用工具的文章提供给了一个强大的模型，并要求它识别哪些步骤真正需要大语言模型，哪些步骤已经稳定到可以表达为代码，然后构建出这个专用工具。

In other words, the natural-language skill served as a high-level specification, while the traces supplied the operational detail that was the result of reasoning by the model.换句话说，自然语言技能充当了高层规范，而轨迹则提供了作为模型推理结果的操作细节。

This is why I think the compiler analogy is useful. We begin with a flexible, high-level representation of intent. After the workflow has been exercised enough to reveal its real shape, we lower the stable parts into a more efficient representation.这就是为什么我认为“编译器”这个类比很有用。我们从灵活的高层意图表示开始。在工作流经过充分运行并显现出其真实形态后，我们将稳定的部分降低（lower）为更高效的表示形式。

The model is still used where necessary. The goal of this whole exercise is differentiating between the workflow parts that can be deterministic code and those that need language understanding, generation or reasoning. We haven’t tried to turn language understanding into a pile of brittle rules. Candidate selection depends on what the source says and whether it would make an interesting post. Drafting obviously benefits from language generation. Those remain model calls because they are model-shaped problems.模型在必要时仍然会被使用。整个练习的目标是区分工作流中哪些部分可以是确定性代码，哪些部分需要语言理解、生成或推理。我们并没有试图将语言理解变成一堆脆弱的规则。候选内容的选择取决于来源内容以及它是否能成为一篇有趣的帖子。撰写草稿显然得益于语言生成。这些部分仍然保留模型调用，因为它们属于“模型擅长处理的问题”。

Start fluid, then optimize先保持灵活，再进行优化

Writing the specialized harness from day one would have been premature. I didn’t yet know the exact workflow, which rules would matter, or where judgment would be required. The natural-language skill version let me discover those things by running the process repeatedly.从第一天起就编写专用工具会显得操之过急。那时我还不了解确切的工作流、哪些规则重要，或者哪里需要判断。自然语言技能版本让我通过反复运行该流程来发现这些细节。

But keeping the entire workflow in natural language forever would mean paying the model to rediscover the same plan on every run.但如果永远将整个工作流保留在自然语言中，就意味着每次运行都要付钱让模型重新发现同一个计划。

The useful pattern is:有效的模式是：

  1. Express the workflow as a natural-language skill.将工作流表达为自然语言技能。
  2. Run it enough times to gather traces and refine the behavior.运行足够多次以收集轨迹并优化行为。
  3. Find the parts that have become stable and deterministic.找出那些已经变得稳定且具有确定性的部分。
  4. Compile those parts into code.将这些部分编译成代码。
  5. Keep LLM calls at the few points where semantic judgment matters.仅在需要语义判断的少数几个点保留大语言模型调用。

There is a one-time cost to this compilation pass. I used a powerful model and a fair amount of context to inspect the traces and produce the new harness. But that cost is paid once. The compiled workflow can then run hundreds or thousands of times, saving tokens and time on every execution. This is standard optimization economics: spend once, amortize over repeated use.这种编译过程有一次性的成本。我使用了一个强大的模型和相当多的上下文来检查轨迹并生成新的工具。但这种成本只需支付一次。编译后的工作流随后可以运行成百上千次，每次执行都能节省 Token 和时间。这是标准的优化经济学：一次性投入，通过重复使用来摊销成本。

I’ve grown to prefer local agents partly because they accumulate exactly this kind of history: skills, traces, state, and the artifacts of prior runs. That history doesn’t just help the agent remember. It gives us the raw material for making the harness itself better.我越来越倾向于使用本地代理，部分原因在于它们能够积累这类历史记录：技能、轨迹、状态以及之前运行的产物。这些历史记录不仅能帮助代理记忆，还为我们改进工具本身提供了原材料。

The long-term economics of agents will depend on this. If every recurring workflow keeps using a frontier model as its planner, state machine, and glue code forever, the cost and latency never really settle down. A specialized harness lets the model concentrate on the small fraction of the workflow that benefits from intelligence.代理的长期经济效益将取决于此。如果每个循环工作流都一直使用前沿模型作为其规划器、状态机和粘合代码，那么成本和延迟就永远无法真正稳定下来。一个专用的工具可以让模型专注于工作流中那一小部分真正能从智能中获益的部分。

Follow the incentives遵循激励机制

There’s another reason I don’t expect these techniques to come primarily from the big model vendors: their business is selling tokens. Preferably lots of tokens from their most powerful and expensive models.我不指望这些技术主要来自大型模型供应商，还有另一个原因：他们的业务就是销售 Token。最好是销售来自他们最强大、最昂贵模型的海量 Token。

There’s an old line: it’s very hard to convince someone of something when their salary depends on not understanding it. Incentives explain behavior and outcomes. A technique that preserves output quality while cutting token consumption by 94% goes straight against the current economics of a company whose revenue rises with token usage.有句老话：如果一个人的薪水取决于他不理解某件事，那么要让他理解这件事是非常困难的。激励机制解释了行为和结果。一种在保持输出质量的同时将 Token 消耗量降低 94% 的技术，直接违背了那些收入随 Token 使用量增长的公司的经济利益。

I’m not claiming that nobody inside those companies cares about efficiency. Obviously they do. Better inference, caching, and cheaper models make their products more useful. But there’s a difference between making each token cheaper and helping a customer discover that most of their workflow doesn’t need tokens at all.我并不是说这些公司内部没有人关心效率。显然他们关心。更好的推理、缓存和更便宜的模型确实使他们的产品更有用。但“让每个 Token 更便宜”与“帮助客户发现他们大部分工作流根本不需要 Token”之间是有区别的。

At least right now, I don’t see much incentive for the major vendors to push that second idea hard. So it’s up to users and independent builders to find these optimization opportunities ourselves.至少目前看来，我没有看到大型供应商有太大动力去积极推广后一种理念。因此，寻找这些优化机会的任务得由我们用户和独立开发者自己来完成。

And that’s also the opportunity. There’s a large open space for founders building specialized harnesses, compilers, and tools that examine recurring agent workflows and move the deterministic parts into code. The value proposition is unusually concrete: keep the output quality, while cutting the cost and latency of producing it.这也是机会所在。对于那些构建专用工具、编译器和工具的开发者来说，有一个巨大的开放空间，可以用来检查循环代理工作流并将确定性部分转化为代码。其价值主张异常具体：在保持输出质量的同时，降低生产成本和延迟。

The model vendors will keep building more powerful engines. Someone still has to make sure we aren’t revving those engines to do simple, deterministic work.模型供应商将继续构建更强大的引擎。但仍然需要有人来确保我们没有在做简单、确定性的工作时过度损耗这些引擎。

Use natural language to discover the workflow. Use traces to understand it. Then compile what has crystallized.利用自然语言来发现工作流。利用轨迹来理解它。然后，将已经结晶的部分编译出来。

Want to try it yourself? Grab the full Token Shrinker prompt and drop it into your agent.想亲自尝试一下吗？获取完整的 Token Shrinker 提示词并将其放入你的代理中吧。