Linear Thinking, Nonlinear Costs线性思维，非线性成本

Many AI agent systems become economically unsustainable long before they become technically impressive. Teams usually focus on model choice, prompt design, tool calling, and orchestration. Those things matter, but they are only part of the system setup. The deeper issue is that coding agents, such as Claude Code, Codex, and Jules, make agent workflows easier to generate. But when implementation is abstracted away, the underlying mechanics become harder to see. Bad engineering used to produce slow code. Now it produces expensive systems that also happen to be slow.许多AI智能体系统在技术上令人印象深刻之前，经济上早已不可持续。团队通常关注模型选择、提示设计、工具调用和编排。这些固然重要，但只是系统设置的一部分。更深层的问题是，编码智能体（如Claude Code、Codex和Jules）使得智能体工作流更容易生成。但当实现被抽象化后，底层机制就变得更难看清。糟糕的工程过去产生慢速代码，现在则产生既慢又昂贵的系统。

When we design agent systems, we still need to remember that the costs scale nonlinearly. A single user request rarely triggers a single model call. It expands into routing, retrieval, reasoning, reflection, guardrail checks, tool calls, and synthesis. Each step may repeat shared context, reload state, recompute a planner decision, or retry a failed path. What looks like an intelligent workflow can therefore behave like a recursive, stateful computation with overlapping subproblems. If that sounds like backtracking, dynamic programming, and memoization to you, you’re right.在设计智能体系统时，我们仍需记住成本是非线性增长的。单个用户请求很少只触发一次模型调用，它会扩展为路由、检索、推理、反思、护栏检查、工具调用和综合。每一步都可能重复共享上下文、重新加载状态、重新计算规划器决策或重试失败路径。因此，看似智能的工作流实际上可能像一个递归的、有状态的、子问题重叠的计算。如果这让你联想到回溯、动态规划和记忆化，那么你是对的。

We already know how to optimize systems like this. The problem is that coding agents make agent systems easier to generate, but not necessarily easier to optimize. Unless we recognize the underlying mechanics, we may never ask our coding agents to apply the optimization patterns that keep our systems viable.我们已经知道如何优化这类系统。问题在于，编码智能体使智能体系统更容易生成，但不一定更容易优化。除非我们认识到底层机制，否则我们可能永远不会要求编码智能体应用那些保持系统可行的优化模式。

Old problems wearing new clothes旧问题穿新衣

When we use coding agents to generate agent architectures, it’s tempting to stop at “the trace looks reasonable.” The tool can generate routers, retrievers, planners, evaluators, guardrails, tool interfaces, and synthesis steps. It may also know about caching, pruning, memoization, and state modeling. But it won’t necessarily implement those patterns unless you ask for these optimization layers explicitly.当我们使用编码智能体生成智能体架构时，很容易止步于“追踪看起来合理”。工具可以生成路由器、检索器、规划器、评估器、护栏、工具接口和综合步骤。它也可能知道缓存、剪枝、记忆化和状态建模。但除非你明确要求这些优化层，否则它不一定会实现这些模式。

Even if you work with agent instructions, unless your SKILL.md, AGENTS.md, or project instructions include constraints around repeated context, memoization, cache invalidation, pruning, and cost per request, your resulting agent system may be functionally correct and economically wasteful at the same time. That’s the tricky part: The code can pass review, the unit tests can pass, and the architecture can look reasonable. The invoice is where the hidden computation finally shows up.即使你使用智能体指令，除非你的SKILL.md、AGENTS.md或项目指令包含关于重复上下文、记忆化、缓存失效、剪枝和每次请求成本的约束，否则生成的智能体系统可能功能正确但经济浪费。这就是棘手之处：代码可以通过审查，单元测试可以通过，架构看起来合理。账单才是隐藏计算最终显现的地方。

It’s easy to give too much agency to tools like Claude Code. When a coding agent reasons in language, calls tools, reflects, and produces fluent text or code, it can feel like a knowledgeable coworker. At the interface level, that impression is understandable. These tools help teams generate more code, move faster, and become more productive. Still, this doesn’t remove the need for engineering craft underneath. Someone still has to recognize repeated context, recomputed planner decisions, correlated retries, unpruned branches, and state that can’t be reused. The coding agent can implement the system, but the engineer still has to understand what kind of system should be implemented. This is where old computer science returns, not as theory but as the optimization layer our agent systems need in production.很容易给Claude Code这样的工具过多的自主权。当编码智能体用语言推理、调用工具、反思并生成流畅的文本或代码时，它感觉像一位知识渊博的同事。在接口层面，这种印象可以理解。这些工具帮助团队生成更多代码、更快行动、提高生产力。然而，这并没有消除底层工程技艺的需求。仍然需要有人识别重复上下文、重新计算的规划器决策、相关的重试、未剪枝的分支以及无法复用的状态。编码智能体可以实现系统，但工程师仍需理解应该实现什么样的系统。这就是旧计算机科学回归的地方——不是作为理论，而是作为生产环境中智能体系统所需的优化层。

The cost multiplier, repeated-work problems, and backtracking成本倍增器、重复工作问题和回溯

The cost multiplier often shows up first as latency. The user doesn’t see the router, the retries, the reflection loop, or the tool calls. They only see that the agent is taking too long. From the outside, the system looks stuck or broken. From the inside, it may simply be repeating work.成本倍增器通常首先表现为延迟。用户看不到路由器、重试、反思循环或工具调用，他们只看到智能体花费太长时间。从外部看，系统似乎卡住或崩溃。从内部看，它可能只是在重复工作。

This is one of the uncomfortable differences between traditional software and agent systems. In a conventional application, a failed operation often throws an error, times out, or leaves a trace that is easy to inspect. In an agent workflow, failure can look like effort to improve reliability. Take the weakest step in your agent workflow. If it succeeds 60% of the time, and you try to push it close to 99% reliability through retries, you need 5 retries:这是传统软件与智能体系统之间令人不适的差异之一。在传统应用中，失败操作通常会抛出错误、超时或留下易于检查的痕迹。在智能体工作流中，失败可能看起来像是为了提高可靠性而付出的努力。以智能体工作流中最薄弱的步骤为例。如果它60%的时间成功，而你试图通过重试将其可靠性提升到接近99%，你需要5次重试：

1 − (1 − 0.60)⁵ = 0.989761 − (1 − 0.60)^5 = 0.98976

This math assumes each retry is a roll of fair dice. LLMs aren’t dice. Whether you’re using greedy decoding or probabilistic sampling, the model is still drawing from the same underlying distribution shaped by your prompt. If the first “thought” is a hallucination or logic error, bumping the temperature won’t fix the underlying state. You aren’t buying independent trials; you’re just sampling different paths through the same flawed map and state.这个计算假设每次重试都是公平的掷骰子。LLM不是骰子。无论你使用贪婪解码还是概率采样，模型仍然从相同的底层分布中抽取，该分布由你的提示塑造。如果第一个“想法”是幻觉或逻辑错误，提高温度不会修复底层状态。你买的不是独立试验；你只是在相同的有缺陷的地图和状态下采样不同的路径。

This is where the old algorithmic framing matters. In a backtracking problem, you don’t keep walking down the same failed branch and call it progress. You return to the last valid state, mark the failed path, and use the failure as information for the next choice. The point isn’t just to try again. The point is to try again under a changed state.这就是旧算法框架重要的地方。在回溯问题中，你不会继续沿着相同的失败分支走下去并称之为进步。你会返回到最后一个有效状态，标记失败路径，并将失败作为下一次选择的信息。关键不仅仅是再试一次，而是在改变的状态下再试一次。

Agent workflows need the same discipline. A retry shouldn’t mean “run it again and hope.” It should give the model structured feedback about why the previous attempt failed: which constraint failed, which tool result was invalid, which schema didn’t validate, which assumption was unsupported, or which branch added nothing. The next attempt should then change something meaningful: the prompt, the tool choice, the retrieved evidence, the validation constraint, or the planner state.智能体工作流需要同样的纪律。重试不应意味着“再运行一次并希望成功”。它应该给模型提供关于上次尝试为何失败的结构化反馈：哪个约束失败、哪个工具结果无效、哪个模式未通过验证、哪个假设无支持、或哪个分支没有增加任何价值。下一次尝试应该改变一些有意义的东西：提示、工具选择、检索到的证据、验证约束或规划器状态。

Memoization, pruning, and dynamic programming记忆化、剪枝和动态规划

Prompt caching is usually the first optimization. If every step repeats the same system prompt, tool definitions, schema constraints, examples, and policy rules, then caching the shared prefix is an obvious win. It reduces the cost of repeated context. But prompt caching only recognizes that text repeats. It doesn’t notice that decisions repeat.提示缓存通常是第一个优化。如果每一步都重复相同的系统提示、工具定义、模式约束、示例和策略规则，那么缓存共享前缀是明显的胜利。它降低了重复上下文的成本。但提示缓存只识别文本重复，它没有注意到决策重复。

In many agent systems, the expensive unit isn’t only text. It’s the repeated decision. If the same or equivalent state appears again, paying the model to rediscover the same action is unnecessary. That is what memoization does: It turns repeated computation into lookup. In classical algorithms, the repeated computation might be a recursive subproblem. In an agent system, it might be a planner decision over the same task, facts, tools, and constraints. The planner can be treated as a function over state:在许多智能体系统中，昂贵的单元不仅仅是文本，而是重复的决策。如果相同或等价的状态再次出现，支付模型重新发现相同动作是不必要的。这就是记忆化的作用：它将重复计算转化为查找。在经典算法中，重复计算可能是递归子问题。在智能体系统中，它可能是关于相同任务、事实、工具和约束的规划器决策。规划器可以被视为一个关于状态的函数：

$$^πLLM(S_t) \rightarrow a_{t+1}$$

π_LLM(S_t) → a_{t+1}

where $S_t$ is the current state of the workflow and $a_{t+1}$ is the next action. Without memoization, this function is evaluated again and again through an LLM call. With memoization, the system first checks whether it has seen the same or equivalent state before. If you want a deeper walkthrough of how to use memoization, I cover it in AI Agents: The Definitive Guide.其中S_t是工作流的当前状态，a_{t+1}是下一个动作。没有记忆化，这个函数通过LLM调用一遍又一遍地评估。有了记忆化，系统首先检查是否见过相同或等价的状态。如果你想更深入地了解如何使用记忆化，我在《AI智能体：权威指南》中有所介绍。

But memoization only helps once the system knows which states are worth revisiting. Pruning handles the other side of the problem: branches that shouldn’t be explored further. However, don’t limit pruning to KV cache pruning or speculative decoding. Use it also when a tool repeatedly returns no new information. Your next LLM call shouldn’t be a slightly reworded version of the same query. If a reflection loop keeps producing stylistic changes without improving correctness, the loop should stop. If a search path violates a constraint or depends on an unsupported assumption, it should be marked as unproductive and removed from the active search space.但记忆化只在系统知道哪些状态值得重新访问时才有帮助。剪枝处理问题的另一面：不应进一步探索的分支。然而，不要将剪枝局限于KV缓存剪枝或推测解码。当工具反复返回无新信息时，也要使用它。你的下一个LLM调用不应是同一查询的略微改写版本。如果反思循环不断产生风格变化而不提高正确性，循环应该停止。如果搜索路径违反约束或依赖无支持的假设，应将其标记为无效并从活动搜索空间中移除。

Dynamic programming becomes relevant when different branches of the workflow solve overlapping subproblems. A research agent may ask similar questions across several documents. A coding agent may inspect the same dependency chain from different entry points. A business analysis agent may compute the same metric for several report sections. If every branch solves these subproblems from scratch, the system pays repeatedly for work it has already done. Table 1 shows examples of how these patterns map to AI agent systems.当工作流的不同分支解决重叠的子问题时，动态规划就变得相关。研究智能体可能跨多个文档提出类似问题。编码智能体可能从不同入口点检查相同的依赖链。业务分析智能体可能为多个报告部分计算相同的指标。如果每个分支都从头解决这些子问题，系统会为已经完成的工作重复付费。表1展示了这些模式如何映射到AI智能体系统的示例。

Table 1. Classical optimization patterns applied to AI agent systems 表1. 应用于AI智能体系统的经典优化模式

This isn’t nostalgia. These patterns mitigate the cost structure of agent systems. Memoization reduces repeated decisions. Pruning reduces repeated failure. Dynamic programming reduces repeated subproblem solving. Together, they form the optimization layer many agent architectures are missing in production.这不是怀旧。这些模式缓解了智能体系统的成本结构。记忆化减少重复决策，剪枝减少重复失败，动态规划减少重复子问题求解。它们共同构成了许多智能体架构在生产中缺失的优化层。

Where to start: Optimization follows topology从何开始：优化跟随拓扑

The patterns above aren’t a checklist you apply uniformly. Each multi-agent topology, whether centralized, decentralized, independent, or hybrid, distributes communication and coordination differently, which directly affects overhead, latency, and failure propagation. The optimization layer has to follow.上述模式并非统一应用的检查清单。每种多智能体拓扑（集中式、分散式、独立式或混合式）以不同方式分配通信和协调，直接影响开销、延迟和故障传播。优化层必须随之调整。

Centralized
A single orchestrator decides, delegates, and aggregates. The expensive unit is the orchestrator’s decision, repeated across similar inputs. Memoize the planner first.集中式：单个编排器决策、委派和聚合。昂贵的单元是编排器的决策，在相似输入中重复。首先对规划器进行记忆化。

Decentralized
Agents coordinate peer-to-peer, exchanging messages without a central authority. The cost moves into the communication itself: redundant exchanges, restated context, agents reasoning over the same shared state from different angles. Prompt caching on the shared context is the first win, followed by pruning exchanges that no longer add information.分散式：智能体点对点协调，交换消息，没有中央权威。成本转移到通信本身：冗余交换、重复上下文、智能体从不同角度推理相同共享状态。对共享上下文进行提示缓存是第一个胜利，随后剪枝不再增加信息的交换。

Independent/swarms
Lightweight agents fan out without coordinating. Cheap individually, expensive in aggregate. If three of your ten agents ask semantically equivalent questions, you pay three times for the same answer. Memoization and pruning aren’t optimizations here; they’re load-bearing.独立/群体：轻量级智能体分散开来，不进行协调。单个便宜，总体昂贵。如果十个智能体中有三个提出语义等价的问题，你为同一个答案付了三次费。记忆化和剪枝在这里不是优化，而是承重结构。

Hybrid
The repeated work shows up at two scales: within a cluster (overlapping subproblems among peers) and across clusters (the coordinator rediscovering the same routing decision). Use dynamic programming on shared subproblems inside the cluster, memoization on the coordinator’s decisions across them.混合：重复工作出现在两个尺度上：集群内部（同行之间重叠的子问题）和集群之间（协调器重新发现相同的路由决策）。在集群内部对共享子问题使用动态规划，在集群之间对协调器的决策使用记忆化。

The optimization layer isn’t a generic discipline you bolt on. It’s a function of the shape of the implementation. Coding agents made it easy to generate the shape without seeing it. The craft is in seeing it anyway.优化层不是事后附加的通用规则，而是实现形状的函数。编码智能体使得生成形状而不看到它变得容易。技艺在于无论如何都要看到它。