一边是招聘端：企业开出 30K-40K 的月薪招 Agent 开发工程师，招不到能解决线上问题的人。另一边是求职端：简历上写满「独立开发 XX 智能体」的开发者，一轮轮挂在工程追问上。

两件事同时成立，而且互为因果。问题不出在会不会用框架——LangChain、LangGraph 这种东西，跟着文档半天就能跑起来。真正卡住双方的，是 Demo 和生产系统之间隔着的一整套工程能力。

这道鸿沟的本质，不在「会不会写 Agent」，而在「能不能管理不确定性」——Demo 只需要在理想环境里跑通一次，生产要求你在网络断连、接口超时、模型幻觉、流量高峰里，每一次都兜得住。

我们把这道鸿沟拆成四块能力拼图：业务拆解与人机协同、高可用工具链与多 Agent 架构、量化评估与运行时防护、工程化交付与持续迭代。只说「要什么」没意义，关键是「长什么样」。所以这篇文章做三件事：按四块能力逐一展开，给每一块配上真实生产环境里的一手案例（Anthropic、Cognition、AWS 的原文我们都读过并核验了数字），给其中三块配上复制就能跑的代码（Python 3.11、零第三方依赖、输出为实跑结果），再给几个流传最广的关键数字补上边界条件。

quote-card

一、鸿沟在哪：Demo 证明「能跑」，生产要求「跑不垮」

先把两边摆在一起：

Demo 环境生产环境
网络与依赖默认永远可用断连、超时、限流是日常
模型输出错了重跑一遍就行幻觉直接面对真实用户
流量一次一个请求高并发，且要求低延迟
成功标准跑通一次连续几个月不出事故

我们的判断是：很多开发者简历好看，缺的是高并发、容错降级、上下文压缩这类工程能力。这不是国内特有的现象，前沿实验室自己也踩过一模一样的坑。Anthropic 在复盘自家多智能体研究系统的文章里承认，早期版本的 agent「会为一个简单查询生出 50 个子 agent，为了不存在的信息源把全网翻个底朝天，还互相用过量的状态更新干扰对方」——连全球顶尖的模型团队，第一版生产 Agent 翻车也是翻在工程上，不是翻在模型上。

反过来，Anthropic 在更早一篇谈如何构建高效 Agent 的文章里有个反直觉的观察：他们合作过的团队里，最成功的实现往往不是用复杂框架搭的，而是用简单、可组合的小模式拼的。两篇文章合在一起，把鸿沟的位置标得很清楚：它不在「框架用得熟不熟」，在「失败来了接不接得住」。Demo 的隐含假设是外部世界永远配合；生产系统的第一性原理是外部世界一定会出问题，你的价值体现在出问题之后的那几秒。后面四块能力，本质上都在回答「出问题之后怎么办」。

二、能力一：把模糊需求拆成可执行的任务图

老板说的是「用 AI 把客服成本降下来」，这不是需求，是愿望。工程化的第一步是翻译成可量化的指标：首次解决率要到多少、转人工率压到多少、单会话成本控制在几毛钱以内。指标定不下来，后面所有技术选型都没有判据。

拆解的第一刀，是判断这件事该不该交给 Agent 做。Anthropic 在《Building effective agents》里划了一条很多人忽略的线：workflow 和 agent 是两种东西——前者是 LLM 和工具按预定义代码路径编排，后者是 LLM 动态指挥自己的流程。他们的建议直白得近乎扫兴：先找最简单的方案，简单到「可能压根不需要 Agent 系统」；定义清晰的任务用 workflow，可预测、一致、便宜。业务拆解能力的第一层不是「怎么拆给 Agent」，是「识别哪部分根本不配用 Agent」——能写成固定流程的部分交给 workflow，LLM 只出现在真正需要判断的节点上，成本和出错面同时缩小。

拆给 Agent 的部分，主流做法是 ReAct 循环——让模型在「思考→行动→观察→调整」的回路里一步步逼近目标，而不是一口气生成完整计划。这个模式出自 Yao 等人 2022 年的论文《ReAct: Synergizing Reasoning and Acting in Language Models》，现在几乎所有 Agent 框架的主循环都是它的变体：

loop:
  thought = llm.think(context)        # 思考：现在进展到哪了
  action  = llm.decide(context)       # 行动：调用哪个工具
  result  = tools.run(action)         # 观察：工具返回了什么
  context.append(thought, action, result)
  if result.indicates_done(): break   # 调整：收敛或继续

拆解完还差最后一道闸：不是所有动作都配得上「自动执行」。涉及大额退款、重要合同这类高风险决策点时，正确的做法是让 Agent 挂起、生成工单交人工审批、拿到结论后再唤醒继续——也就是 Human-in-the-Loop。下面是一个可以直接运行的最小实现（python demo1_hitl.py）：

APPROVAL_THRESHOLD = 500  # 元；超过这个金额必须人工审批

class RefundAgent:
    def __init__(self):
        self.state = "idle"
        self.ticket = None

    def handle_refund(self, order_id: str, amount: float):
        if amount > APPROVAL_THRESHOLD:
            # 高风险动作：挂起，生成工单，交给人
            self.state = "suspended"
            self.ticket = {"type": "refund_approval", "order_id": order_id,
                           "amount": amount, "status": "pending"}
            print(f"[agent] refund {amount} CNY > threshold {APPROVAL_THRESHOLD}, suspending")
            return
        self.state = "running"
        print(f"[agent] refund {amount} CNY <= threshold, executed directly: order {order_id}")
        self.state = "done"

    def on_human_decision(self, approved: bool):
        assert self.state == "suspended", "no suspended task to resume"
        self.ticket["status"] = "approved" if approved else "rejected"
        self.state = "running"  # 带着人工结论唤醒
        if approved:
            print(f"[agent] woke up, ticket approved -> executing refund of {self.ticket['amount']} CNY")
        else:
            print("[agent] woke up, ticket rejected -> refund aborted, notifying user")
        self.state = "done"


agent = RefundAgent()
agent.handle_refund("A-1001", 199)        # 199 元：低于阈值，直接执行
agent2 = RefundAgent()
agent2.handle_refund("A-1002", 5000)      # 5000 元：超过阈值，挂起等审批
agent2.on_human_decision(approved=False)  # 人工驳回 -> 唤醒 -> 终止退款

真实运行结果（小额直过、大额挂起、人工驳回后一分钱没动）：

[agent] refund 199 CNY <= threshold, executed directly: order A-1001
[agent] refund 5000 CNY > threshold 500, suspending
[agent] woke up, ticket rejected -> refund aborted, notifying user

生产框架里，LangGraph 的 interrupt、各类工单系统对接，做的都是同一件事：状态可挂起、可恢复、人工结论能注入。要不要加这道闸，判据不是模型有多准，而是「这一次错了，代价是什么」——不可逆的动作才配走 HITL，可逆的动作加审批只会拖垮体验。

三、能力二：承认失败必然发生，然后设计它

工具调用的第一层功夫在「写得准」：API 描述无歧义、参数边界写清楚、配 Few-Shot 示例做行为对齐。同一个查询工具，描述写成「查询信息」和写成下面这样，模型的调用准确率完全是两回事：

{
  "name": "query_order",
  "description": "按订单号查询订单状态与金额。仅支持已支付订单；退款进度请用 query_refund。",
  "parameters": {"order_id": {"type": "string", "pattern": "^[A-Z]-\\d{4}$"}}
}

但描述写得再好，调用也一定会失败——网络会断、接口会超时、上游会挂。生产标配的三段式容错链路是捕获拦截、指数退避、兜底降级，这里值得补一个很多人不知道的身世：这套东西不是 Agent 时代发明的，它今年十一岁了。2015 年 3 月，AWS 的 Marc Brooker 在官方架构博客发表《Exponential Backoff And Jitter》，用仿真证明了一件事：固定间隔重试会让所有客户端在同一时刻撞上游，撒了随机性的指数退避才能把重试洪峰摊平成近似恒定的低速水流。2023 年 5 月这篇文章更新了一段话：八年后，这个方案依然是亚马逊构建弹性系统客户端库的支柱，AWS 各 SDK 的标准重试模式内置了它。

所以下面这个示例不是玩具，它就是你每天用的 SDK 的重试内核（python demo2_retry_breaker.py，演示把延迟基数从生产的 1 秒缩到 0.1 秒）：

import random, time

random.seed(42)           # 固定随机种子，让演示输出可复现
BASE_DELAY = 0.1          # 演示比例；生产环境用 1.0，即 1s、2s、4s、8s……
MAX_RETRIES = 4
BREAKER_THRESHOLD = 3     # 连续失败 3 次，熔断器断开

class Breaker:
    def __init__(self):
        self.consecutive_failures = 0
        self.state = "closed"

    def record(self, ok: bool):
        if ok:
            self.consecutive_failures = 0
            self.state = "closed"
        else:
            self.consecutive_failures += 1
            if self.consecutive_failures >= BREAKER_THRESHOLD and self.state == "closed":
                self.state = "open"
                print("[breaker] 3 consecutive failures -> open, short-circuiting and alerting")

upstream_calls = 0

def flaky_upstream(fail_times: int):
    """上游模拟：前 fail_times 次调用抛超时，之后恢复正常。"""
    global upstream_calls
    upstream_calls += 1
    if upstream_calls <= fail_times:
        raise TimeoutError("upstream timeout")
    return "real upstream answer"

def call_with_retry_and_fallback(breaker, fail_times: int):
    if breaker.state == "open":
        return "fallback: cached default answer"     # 熔断中：直接走兜底，不调上游
    for attempt in range(MAX_RETRIES + 1):
        try:
            result = flaky_upstream(fail_times)
            breaker.record(ok=True)
            return result
        except TimeoutError:
            breaker.record(ok=False)
            if breaker.state == "open":
                return "fallback: cached default answer"
            if attempt < MAX_RETRIES:
                delay = random.uniform(0, BASE_DELAY * (2 ** attempt))  # 指数退避 + 全抖动
                print(f"[chain] attempt {attempt + 1} failed, retrying in {delay:.2f}s")
                time.sleep(delay)
            else:
                return "fallback: cached default answer"  # 重试耗尽：本地规则兜底

breaker = Breaker()

# 场景一：上游先挂 2 次后恢复 -> 重试生效
r1 = call_with_retry_and_fallback(breaker, fail_times=2)
print(f"[scenario 1] recovered after retries: {r1!r}")

# 场景二：上游持续故障（99 次都失败）-> 重试耗尽 + 熔断器断开
r2 = call_with_retry_and_fallback(breaker, fail_times=99)
print(f"[scenario 2] exhausted retries: {r2!r}")

# 场景三：熔断器仍断开 -> 上游一次都不会被调用
before = upstream_calls
r3 = call_with_retry_and_fallback(breaker, fail_times=99)
print(f"[scenario 3] breaker open, upstream calls unchanged at {upstream_calls}: {r3!r}")

真实运行结果（三个场景连跑）：

[chain] attempt 1 failed, retrying in 0.06s
[chain] attempt 2 failed, retrying in 0.01s
[scenario 1] recovered after retries: 'real upstream answer'
[chain] attempt 1 failed, retrying in 0.03s
[chain] attempt 2 failed, retrying in 0.04s
[breaker] 3 consecutive failures -> open, short-circuiting and alerting
[scenario 2] exhausted retries: 'fallback: cached default answer'
[scenario 3] breaker open, upstream calls unchanged at 6: 'fallback: cached default answer'

三个细节值得停下来看。第一，random.uniform(0, base * 2**attempt) 就是 AWS 那篇文章命名的「Full Jitter」——间隔从 0.06s 缩到 0.01s 不是 bug，全抖动允许单次变短，但期望上限按 2 的幂增长。第二，熔断断开后上游调用数定格在 6 不再增长——对一个正在死的上游继续发请求，烧的是你自己的 token 账单。第三，「熔断 + 报警」这条防天价账单的保险丝，在链路里就是三行代码的事，缺了它，一个死循环的 Agent 一晚上能烧掉的金额没有上限。

前沿实验室在生产里也是同一套思路，只是多了两层 Agent 特有的补丁。Anthropic 的复盘中提到两条：一是出错后从头重启对长任务 Agent 来说「既昂贵又让用户沮丧」，所以他们做的是从断点恢复（checkpoint + resume）；二是「把工具正在失败这件事告诉模型、让它自己调整策略，效果好得出奇」——错误信息不只是日志，也是喂给模型的纠错信号。传统重试治网络，断点恢复治长任务，把失败透传给模型治决策，三层各管一段。

这一节的反面教材只有一行：while True: call_api()。把失败当成「不太可能发生的异常」来祈祷，和把失败当成「统计上必然发生的事件」来设计，是 Demo 工程师和生产工程师的分水岭。

四、能力三：多 Agent 之争，和比架构更重要的上下文账本

业界对架构的常见答案是多 Agent 分工：主控 Agent 调度，财务、库存这些专有 Agent 各司其职。但 2025 年 6 月，这个答案被人公开挑战过，而且挑战者和被挑战者都拿出了真凭实据——这是全年 Agent 工程圈最值得看的一场架，两边都是我们判断的依据。

正方 Anthropic，用数字说话。 他们的研究系统采用 orchestrator-worker 模式（主 Agent 协调、子 Agent 并行），实测结果是：Claude Opus 4 做主控、Claude Sonnet 4 做子 Agent 的多智能体系统，在内部研究评测上比单个 Claude Opus 4 强 90.2%——比如「找出标普 500 信息技术板块所有公司的董事会成员」这种广度优先任务，多 Agent 把大问题切成互不依赖的方向同时推进，优势是结构性的。但同一篇文章把代价也写得明明白白：普通 Agent 的 token 消耗大约是聊天的 4 倍，多智能体系统大约是 15 倍。原话的经济学结论很冷：多智能体要成立，任务本身的价值必须高到付得起这笔 token 溢价。

反方 Cognition（Devin 的团队），用原则说话。 Walden Yan 在 6 月 12 日的《Don’t Build Multi-Agents》里给出两条上下文工程原则：共享上下文（而且是共享完整的执行轨迹，不是只转述几条消息）；动作携带隐性决策——两个子 Agent 分头干活，各自做的假设互相不知道，合起来必然打架。他举的例子很具体：让两个子 Agent 分头做 Flappy Bird 的「移动背景」和「小鸟」，两边对重力和操控手感的隐性假设对不上，拼出来的东西没法玩。他的默认建议是用单线程线性 Agent，并且观察到一个佐证：Claude Code 虽然会派生子任务，但子任务只负责回答问题，从不和主 Agent 并行写代码。

两边矛盾吗？我们的裁决是：不矛盾，分歧点在任务结构。研究类任务广度优先、子方向互不依赖，隐性决策少，多 Agent 的 15 倍 token 买得到 90% 的能力提升；写代码类任务强耦合、隐性决策密集，Cognition 的两条原则一碰就碎。判据只有一个：你的子任务之间需要共享多少隐性决策——需要得越多，越该待在同一个上下文里。

多 Agent 之争：15 倍 token 换 90.2% 提升，值不值看任务结构

比架构之争更日常的是上下文本身的账。长对话有两个明账：token 费用随轮次涨，模型对早期内容的记忆随距离模糊。Anthropic 那篇文章还有个容易被忽略的量化结论：在 BrowseComp 评测里，token 用量这一个因素解释了表现方差的 80%，超过工具调用次数和模型选择——上下文就是这门生意里最硬的通货，怎么花它直接决定系统能力的上限。工程解法是两件事配合：关键语义显式提取、常驻 prompt（或存向量库按需取回），闲聊类历史用滑动窗口按时间淘汰。最小可运行示例（python demo3_context_window.py；token 数用 len(text)//2 估算仅为演示，生产要用模型对应的真实 tokenizer）：

def est_tokens(text: str) -> int:
    return max(1, len(text) // 2)  # 演示估算；生产用真实 tokenizer

BUDGET = 120  # token 预算，故意调小让效果可见

system_prompt = "你是客服 Agent，只处理订单问题。已知关键事实：订单号 A-1001，金额 5000 元，状态：待人工审批。"
history = [f"第{i}轮闲聊内容：" + "嗯。" * 10 for i in range(1, 13)]  # 12 轮低价值历史
recent = ["用户：我的退款到底什么时候到账？",
          "Agent：查询中，订单 A-1001 的退款金额为 5000 元，需要人工审批。"]

full = [system_prompt] + history + recent
print(f"[before] {len(full)} messages, ~{sum(est_tokens(m) for m in full)} tokens (budget {BUDGET})")

windowed = [system_prompt]                      # pinned：系统提示与关键事实永驻
for msg in reversed(recent + history[-2:]):     # 从最新往最旧装
    if sum(est_tokens(m) for m in windowed) + est_tokens(msg) <= BUDGET:
        windowed.insert(1, msg)
    else:
        break

print(f"[after]  {len(windowed)} messages, ~{sum(est_tokens(m) for m in windowed)} tokens; "
      f"dropped {len(full) - len(windowed)} old turns")

assert sum(est_tokens(m) for m in windowed) <= BUDGET
assert any("A-1001" in m for m in windowed), "pinned 关键事实必须在压缩后存活"
print("[ok] budget met; pinned facts survive; oldest low-value turns evicted")

真实运行结果：

[before] 15 messages, ~224 tokens (budget 120)
[after]  5 messages, ~84 tokens; dropped 10 old turns
[ok] budget met; pinned facts survive; oldest low-value turns evicted

关键不在省了多少 token，在「什么活下来了」：订单号 A-1001 被 pinned 在系统提示里，无论窗口怎么滑都不会丢；被扔掉的是最老的 10 轮闲聊。只用一个裸滑动窗口、不做事实提取的实现，早晚会把用户三分钟前报的订单号滑出去——上下文窗口是预算，不是仓库，预算就该花在刀口上。

五、能力四：没有度量，就没有生产

招聘 JD 和技术分享里最常出现的三个指标是：任务完成率 95% 以上、工具调用异常率 1% 以内、P99 响应延迟 500ms 以内。方向都对，但直接照搬会踩坑，边界条件补上：

  • 95% 完成率：先定义「完成」才有资格谈达标。单轮问答的完成和多步任务的完成是两回事——后者是每步成功率的连乘，10 步的任务每步 99%，全链只剩 90% 左右。口径不定义清楚，95% 只是个好看的数字。
  • 1% 工具异常率：四个指标里最可以直接照搬的一个，因为它度量的是你自己的工程链路，不依赖模型发挥。
  • P99 500ms：对多步 LLM 链路，这个数字通常只能约束「非模型环节」——工具调用、检索、鉴权这些你自己写的代码；或者约束首 token 延迟。LLM 生成本身常常是秒级的，全链路 500ms 要靠流式输出、并发调用、缓存去逼近，多数场景根本达不到。面试里把这三个数背成教条的人，恰好暴露了他没在生产里追过这些指标。

三大黄金指标及其边界条件

比单个指标更重要的是评估体系本身。Hamel Husain 在 2024 年 3 月的《Your AI Product Needs Evals》里下过一句重话：他见过的不成功的 AI 产品，几乎都有同一个病根——没有建立起像样的评估系统。他给的阶梯是三级：第一层是廉价的单元测试式断言；第二层是人工审查加模型评分（LLM-as-a-Judge 就在这一层，配合 trace 日志）；第三层是 A/B 测试。「提交代码时让顶尖模型当裁判」这个越来越常见的做法不是孤立技巧，是这套阶梯的第二级——没有第一层的硬断言兜底、没有第三层的真实流量校验，光靠裁判模型打分，你会拥有一个看起来在守门、其实在放水的测试体系：裁判模型自己也会漂移，评估集要版本化，裁判结论要定期抽人复核。

指标之外是运行时防护。两个安全网必须有：一是防死循环，靠步数计数器和执行深度上限硬打断——实现上就是循环里一行 if steps > MAX_STEPS: break，但必须显式存在，不存在就等于给无限循环签发许可证。二是接口熔断，第三节已经演示：连续失败切断调用并报警，既保护上游也保护账单。

说到底，你度量什么，Agent 系统才优化什么——没定义完成率之前谈「提升效果」，都是在用感觉工程。

六、把能力变成流程：工程化交付与持续迭代

最后一块拼图不在代码里，在流程里。有三件事值得单独说，我们各配一个前沿实验室的真实做法：

  1. LLM-as-a-Judge 进 CI。Hamel 的文章里提到，地产 AI 助手 Lucy 背后的 Rechat 团队直接用 GitHub Actions 这类 CI 设施跑评估测试——提交即回归，不是什么未来愿景。
  2. 灰度发布与无损回滚。Anthropic 的多智能体系统用的是「rainbow deployment」：新旧版本同时在线，流量逐步从旧切到新。为什么不能像普通服务那样直接切？因为 Agent 是长任务，强制切断等于把用户跑到一半的进度扔进垃圾桶——他们原话是「我们没法同时把所有 Agent 更新到新版本」。业内常说的「先切 5% 流量、报错率一高毫秒级切回」是同一个思想，只是 Agent 版的灰度还要额外照顾在途任务。
  3. 分布式追踪 Trace ID。Anthropic 的做法是给全链路加上完整的生产追踪，但有个值得抄的细节：他们只追踪 Agent 的决策模式和交互结构，不追踪对话内容本身——既能在「用户报告 Agent 找不到明显信息」时定位到底是查询词烂了、信息源选错了还是工具挂了，又不碰用户隐私。多 Agent 系统没有 Trace ID，出事故约等于裸奔。

这三件事没有一件是 Agent 时代的新发明——全是传统 SRE 实践向概率系统的平移，连名字都没换。这恰好印证了开头的判断：Agent 工程的核心不是新魔法，而是把确定性工程的老功夫，套在一个本质不确定的模型外面。

总结：四块拼图回答的是同一个问题

能力回答的根本问题关键手段（真实出处）
业务拆解与人机协同模糊的商业愿望怎么变成可验收的机器任务workflow/agent 分界线（Anthropic）、ReAct、HITL 挂起唤醒
高可用工具链与容错失败必然发生，怎么不让它变成事故Full Jitter 退避（AWS 2015）、熔断、兜底、断点恢复（Anthropic）
多 Agent 与上下文控制能力和成本怎么同时管住orchestrator-worker（Anthropic，15× token 换 90.2%）、上下文两原则（Cognition）、滑动窗口 + pinned facts
量化评估与工程交付怎么知道系统在变好而不是在变贵评估三级阶梯（Hamel）、rainbow deployment、全链路 trace

四行合起来是一句话：生产级 Agent 工程师的工作，是给一个概率系统套上确定性的外壳，并且能说清这个外壳每一层的厚度。会写 Demo 证明你能让模型动起来；能讲清每一层外壳怎么兜住失败、怎么度量、怎么回滚，才证明你能让它活下来。这就是 30K 的招聘启事和石沉大海的简历之间，真正隔着的东西。

FAQ

写 Demo 和生产级 Agent 开发的差距到底在哪？

Demo 只需在理想环境跑通一次；生产要求在网络断连、接口超时、模型幻觉、高并发下每次都兜住。差距不在框架熟练度，在容错、评估、灰度这类把不确定性压进 SLA 的工程能力。

多智能体（Multi-Agent）架构到底该不该上？

看子任务耦合度。Anthropic 的实测是多智能体在研究类任务上比单智能体强 90.2%，但 token 消耗是聊天的 15 倍；Cognition 的立场是默认单线程，除非子任务不需要共享隐性决策。两边不矛盾，判据是任务结构。

任务完成率 95%、P99 500ms 这类指标可以直接照搬吗？

不能直接照搬。95% 取决于你怎么定义「完成」；500ms 对多步 LLM 链路通常只能约束非模型环节或首 token 延迟。先定义口径，再谈达标。

人机协同（Human-in-the-Loop）什么时候必须加？

动作不可逆且损失超过你能承受的上限时必须加：大额退款、合同签署、删除类操作。判据不是模型准确率，而是「这一次错了代价是什么」。

资料出处

  • 本文的框架整合、观点与「确定性外壳」的解读为「梦兽编程」原创；以下外部资料仅用于案例与数字佐证，关键引用均已对照原文核验。
  • Anthropic 工程博客《How we built our multi-agent research system 》（Jeremy Hadfield 等，2025 年 6 月）：多智能体强 90.2%、Agent 约 4 倍 token、多智能体约 15 倍 token、token 用量解释 80% 方差、「50 个子 Agent」早期翻车细节、断点恢复、rainbow deployment、不追踪内容的全链路 trace，均出自此文。
  • Anthropic 工程博客《Building effective agents 》（2024 年 12 月）：workflow 与 agent 的区分、「找最简单方案，可能根本不需要 Agent 系统」、成功实现多为简单可组合模式的观察，出自此文。
  • Cognition 博客《Don’t Build Multi-Agents 》（Walden Yan，2025 年 6 月 12 日）：共享完整上下文轨迹、动作携带隐性决策两条原则，Flappy Bird 案例与 Claude Code 佐证，出自此文。
  • AWS 架构博客《Exponential Backoff And Jitter 》（Marc Brooker，2015 年 3 月 4 日，2023 年 5 月更新）：Full Jitter 命名与「八年后仍是支柱」的更新说明出自此文；本文 demo2 的退避实现即 Full Jitter。
  • Hamel Husain《Your AI Product Needs Evals 》（2024 年 3 月 29 日）：评估三级阶梯、「不成功的 AI 产品几乎都有同一个病根」、Rechat 用 CI 跑评估，出自此文。
  • ReAct 模式出自 Yao 等人 2022 年的论文《ReAct: Synergizing Reasoning and Acting in Language Models》（arXiv 可搜）。
  • 文中三段代码均为 Python 3.11 标准库实现，发布前在本机真实运行通过，输出为实跑结果；延迟数字为演示比例（0.1s 基数），生产环境对应 1s、2s、4s、8s。

相关阅读

多 Agent 之争，你站哪边

第四节那场架，你的立场是什么：

  • A. Anthropic 派：广度优先的任务就该多 Agent 并行，15 倍 token 买到 90.2% 的提升，值
  • B. Cognition 派：默认单线程线性 Agent，上下文连续高于一切，并行是脆弱性的来源
  • C. 看任务下菜：子任务弱耦合上多 Agent，强耦合守单线程，判据是隐性决策的密度

评论区说出你的选择和理由。尤其欢迎真的在生产里跑过多 Agent 系统的人——你的 token 账单和翻车记录，比两边的十段论点都值钱。

如果你想自测水平，把文中三段代码拷下来跑一遍，再回答一个问题：你的 Agent 上一次故障，是死在重试、熔断、还是上下文里？把答案贴在评论区，下周我们挑最典型的几个故障案例写成续篇。

觉得这篇文章说清了你团队的现状，转发给那个正在准备 Agent 岗位面试、或者正在面 Agent 工程师的同事——这道鸿沟，两边的人都该看看对面长什么样。

关于「全栈之巅-梦兽编程」：专注 AI 编程与全栈技术深度内容，微信搜索「梦兽编程」关注公众号，获取更多 Rust 与 AI 编程实战教程。