第 15 章 人机协同与生产化

本章解决生产化里最后一件要定的事，权限给多少；demo 里的智能体出点错，代价最多是一段不对劲的输出，进了生产，接触真实数据、真实群聊和真实订单，同样的错误立刻升级成事故，所以第一个要设计的往往不是怎么让它更能干，而是把关键决策权留在人这边、经人确认再执行，这个设计就是人机协同（Human-in-the-Loop）。15.1 给四种形态（工具审批、澄清请求、里程碑确认和暂停恢复）各自的适用场景、粒度与成本，末尾转到用户侧给四条 UX 原则；15.2 把最常用的审批与澄清装成一条跑得起来的回路；15.3 讲渐进自主，放多少权拿第 12 章的评测数字说话，不凭感觉；15.4 定部署形态，同步 API 服务、长任务 worker 和离线批量各接一类场景；15.5 讲水平扩展、容量规划、离线模拟、影子测试与金丝雀；15.6 用连锁品牌线走完从周末 demo 到真正上线的完整改造。全自主是终点，不是起点，人在哪里拦、拦到什么程度、系统跑在哪里，这一章逐节给出答案；反过来，拿人机协同当产品还没成熟的借口、走一步确认一次，智能体就退化成一条高成本的人工流程。

15.1 人机协同的四种形态

该在哪儿拦、用什么方式拦、拦到什么时候，业界的答案归成四种形态，工具审批、澄清请求、里程碑确认和暂停恢复。这道题只在生产里出现，demo 阶段脚本只在本地跑，群消息一直由人手动点按钮；等上了生产，群发工具进了模型的工具清单，发出去的消息收不回，拦不拦就成了绕不开的选择。拿运营助手来说，它做完华东大区昨天的复盘，下一步要发进 42 家店的运营群，这一步就是典型的拦截点，不发，这份复盘等于白做。

这四种形态不是凭空想出来的，背后是交互方式的转变，过去用户直接操纵软件，如今改成把任务委托出去。传统软件里每个按钮会触发什么，都固定在界面上；智能体系统里用户只讲目标，具体做哪几步由模型当场来定，用户这边随之多出四条新诉求。哪类任务交给它干得了，用户得摸得清，这是能力发现；动作要付出什么代价，得看得见，这是成本感知；它正在做什么，得看得见，这是可观测性；随时能喊停，这是可中断。四条合起来就是智能体界面的 UX 原则，本节末尾逐条展开。

四种形态里粒度最细、也最常见的是工具审批（tool approval）。审批点挂在单个工具调用上，模型照常把调用发出来，只是执行之前得先过人的手。什么时候需要这一关，判据在第 13 章的 Rule of Two 里已经写清，不可信输入、敏感数据、改变状态或对外通信三条全占的会话，不允许自主运行。第 10 章谈人类委派时也讲过一句，规则打底、模型补充，高风险动作都由规则截下来转给人工。

这一节补上的是执行机构，前面只讲了判据，这里讲判据怎么写进代码。第 8 章 8.1 用 pending_tool_call 加 FileSessionManager 给出过最小实现，做法是执行到需要审批的工具就先停下来，把这次调用序列化进会话状态，等审批结果回来，再带着决定把执行续上。

各家框架的实现里有一个做法是共通的，审批标记写在工具定义上，不放进系统提示。有的实现给工具挂 requires_confirmation 属性，配上提示消息模板，有的用 approval_mode 标记把工具设成始终需要审批。做法不同，思路一样，都让执行器查表判断，而不是赌模型读完提示会自己停。模型的行为带概率，代码的判断是确定的，安全组件只放在确定的那一侧。

围绕这个形态还有三条设计细节，都是审批真跑起来之后吃过亏才定下的。第一条，审批的时机必须卡在执行之前。事情做完了再回头问一句那么做行不行，对删文件、发消息这类不能撤回的动作毫无价值，消息已经发进群里了，批准来得再快也改变不了结果，所以这条从一开始就是设计上的硬规则。

批准也能只批其中一部分。模型一次发出三个调用，人批了两个、驳了一个，凡没进批准清单的调用一律按驳回处理，这套做法就是白名单式批准。

驳回与改参同样是信息。驳回要原样回填给模型，模型会绕开这一路，把任务的其余部分做完。人也可能在批准时顺手改参数，比方说放行发消息、却把目标群换掉，改动后的参数跟着决定一起回到执行流。

这道闸还立在一个前提上，来审的人会认真审。麻烦在于这个前提自己会坏。审批一件接一件来，人越批越快，材料没看全就点了通过，闸还立在原地，把关已经空了。14.4 第十条给过一个信号，审批通过率长期居高，那边的读法是标准定得过紧；同一个数字还有第二种原因，审的人早就不审了。光看通过率分不出这两种情况，得配上平均审阅时长一起盯，通过率居高、审阅时长不断缩短，人就是在空转。对策顺着两头走。监测上，两个数一起看，谁异常都停下来问一句为什么；设计上，送审的条目得自带足够的上下文，打算做什么、凭什么判断安全，让人一眼能判，把监督者拖疲拖垮的流程本身就是缺陷，别指望拿人的敬业去填。

澄清请求（clarification request）拦截的对象换了一种。审批拦的是动作，模型已经拿定主意要做什么，人只需点头或摇头。澄清拦的是理解，任务的规格有缺口，缺的信息只存在人的脑子里。把昨天的复盘发到群里，这个命令里，昨天指哪天、发到哪个群、带不带竞对数据，任何一处含糊，任务都会做偏。

两种机制还差在答案的形态上。审批的答案接近二值，澄清拿回来的是一段信息，这段信息补进上下文，任务才谈得上真正开始。

实现仍沿用第 4 章那条老路。把提问做成一个工具，模型调用它之后，执行器不做任何动作，只把问题交回界面，人的回答再以工具结果的身份写回历史。

有一种轻量做法，在指令里约定一个输出前缀，回答以 CLARIFICATION NEEDED 开头就停，机器判断起来很简单，代价是提问没有进入消息协议。做成工具，提问本身就进了协议，参数还能约束问题的结构。约束提问行为的提示模板放在下面。

你是连锁品牌的运营助手。回答或动手之前，先判断信息是否够用。缺会改变
执行结果的关键信息时，调用 ask_user 工具提问，一次只问一处，问题里给出
候选项；信息够用时直接完成任务，不再回头确认。关键信息指门店编号、
日期口径、发送对象这类字段。

### 示例
输入：把昨天的复盘发到群里
ask_user 参数：{"question": "发到哪个群？华东大区运营群（42 家店）还是督导群（8 人）？"}

### 输入数据
输入：{user_input}

澄清请求问的是眼前这位用户，可任务缺的关键信息，有时他也没法当场答上来，缺口在还没收回的报表里，在别的部门同事的脑子里。这时候补缺口的动作可以更主动，派一个子智能体专门去收数据，找对应的人问、发问卷、把数凑齐，回来再交任务，而不是带着缺口先把决定做了。方向正好跟澄清请求相反，一边是人把信息递给智能体，一边是智能体自己把信息收上来。判断缺口在哪的功夫是同一套，差在补齐的方式。医疗行业已有现成做法，出院规划这类智能体发现关键信息缺失，会提示临床医生补齐，或者直接给患者发问卷。

澄清追问之外，界面本身也能替模型干活，这类做法现在有个通行的叫法，生成式界面（generative UI）。第 5 章 5.4 的 MCP Apps 就是一路，工具结果旁边附一份自包含的小应用，宿主放在沙箱里渲染出来。顺着这个思路还有两种常见做法。一种是拿界面补信息缺口，与其让模型一轮一轮地追问，不如当场生成一张动态表单，缺哪些字段、各带什么候选项一次摆全，人填一遍，缺口一次补齐。另一种是拿界面出数据类的产出，模型只负责写查询语句和可视化的代码，执行交给系统，数据从头到尾不经过模型的手，token 省下来，也堵掉了一层模型顺手改数字的风险。两种做法还得守住同一条边界，界面组件一律从白名单里挑着渲染，不许让模型直接往页面里吐任意的前端代码。

里程碑确认（milestone confirmation）把拦截的粒度从单个动作抬高到阶段。任务一长，逐个动作去审批根本审不过来，整条流程直接放行又不踏实，折中起来就是先批方案、再验节点。动手之前智能体先交一份计划，计划通过才开工。跑到一个里程碑就停下，把这阶段的交付物交到人眼前，确认过再继续。

验收一侧的机制，第 10 章计划式的步骤验收已经给过；停下再续跑的机制，第 8 章的检查点也备好了。里程碑确认做的事，是把这两样拼起来，外加一道人工闸门。

成本算起来不难。批方案的人一次确认盖掉一整段，任务越长，摊到每一步的审批工夫越少。代价也摆在明处，两次确认之间，智能体全在自己跑，中间那些步没有人盯着。所以里程碑的切分得贴着不可逆动作走，确认点放在下一个收不回头的动作之前，这一次点头才算真挡住了事；放进一堆可逆步骤中间，批与不批其实差不了多少。

这一形态装成代码，方案先过人，每个里程碑停下等确认，状态全程留在会话里。

"""示意代码：里程碑确认的最小回路，python3 可直接运行。"""

# 周报分三个里程碑（各步执行都是桩，真实实现接 15.6 的周报流水线）
MILESTONES = [
    ("取数", "两厂上周指标齐备"),
    ("分析", "归因结论三条，附证据指针"),
    ("成稿", "周报初稿，含指标概览与异常归因"),
]

def human_gate(name: str, deliverable: str) -> bool:
    """人工闸门（桩）：接审批队列，人点头才放行，这里直接演示通过。"""
    print(f"[里程碑 {name}] 交付：{deliverable}。确认：通过")
    return True

def run_with_milestones(plan: list) -> str:
    """先批方案再开工，每个里程碑停下等确认，状态全程留在会话里。"""
    session = {"step": 0, "deliverables": []}
    while session["step"] < len(plan):
        name, deliverable = plan[session["step"]]
        if not human_gate(name, deliverable):
            return f"已暂停在 {name}，会话原样留存，确认后从这里续跑"
        session["deliverables"].append(f"{name}：{deliverable}")
        session["step"] += 1
    return "全部里程碑确认完毕，周报交分析师发送"

if __name__ == "__main__":
    print(run_with_milestones(MILESTONES))

闸门否决时执行就地停住，会话里记着停在第几步，确认回来从那一步接着走；真接生产时把 human_gate 换成审批队列，挂起与续跑的机制 15.2 展开。

暂停恢复（pause and resume）严格说来并不是第四种审批，而是前面三种形态共同依赖的基础。审批的结果可能三分钟后在网页按钮上回来，也可能三天后从邮件里回来，中间隔着进程退出、服务器重启和副本扩缩容，无论哪一样，审批结果回来时，执行都要能接着跑完。

进程重启这一关，第 8 章 8.1 的实现已经跨过去了，这里补的是生产语义。碰到审批，不是占着资源空等，而是把执行整个退出去，全部状态存进可序列化的上下文；审批到了，再起一次新运行，接着原来的进度往下跑。

彻底退出带来四条好处。任何一台服务器都能接下恢复请求，等待期间不占着连接，服务崩溃不会丢掉会话状态，负载均衡也不必依赖会话粘性。这四条到 15.5 谈水平扩展时还会再提。

形态	拦什么	谁发起	等待时长	单位成本	典型场景
工具审批	单个动作	规则触发，标记在工具上	分钟到天	高，逐动作停	删文件、群发、退款
澄清请求	任务理解	模型判断信息缺口	秒到分钟	低，一次往返	规格含糊、口径不一
里程碑确认	阶段方案与交付物	计划节点	小时到天	中，摊到整段	报表批稿、方案评审
暂停恢复	前三者的机制基座	前三者触发	任意	一次序列化	所有异步审批

到这儿为止，拦在哪、怎么拦，答案都在系统这一侧。同一件事换到用户那一侧看，就归成四条 UX 原则。

智能体能做什么、不能做什么，边界并不齐整。哈佛商学院 Dell'Acqua 等人的 2023 年田野实验管这个现象叫参差的前沿（jagged frontier），难度看着很高的任务它可能完成得很漂亮，看着简单的反倒可能失败，用户没法提前判断哪类请求能顺顺当当走完。既然判断不了，界面就得主动把人引到系统有把握的任务上，给现成的示例、给模板，别让用户拿一趟带特殊要求的蜜月行程，去为难一个只会订商务出差的系统。这条对策就是能力发现（capability discovery）。

用户会系统性高估这套系统，还有一条比参差的前沿更老的成因。1966 年，MIT 的约瑟夫·魏泽鲍姆写下聊天程序 ELIZA，本意是演示自然语言处理有多简陋，结果不少用户对着它认真倾诉，有位秘书还请他离开房间，好单独跟程序说心里话。人面对会说人话的东西，会不自觉地替它补上理解、关心甚至智力，这个冲动后来有了个名字，叫 ELIZA 效应（ELIZA effect）。别把它当成六十年代的天真，这股冲动今天还在，设计语言界面躲不开它，今天的模型口才远胜 ELIZA，这份投射只会更重。界面把能力边界讲清楚、把依据摆出来，不只是一条设计原则，也是在替用户抵消这份天性里的高估。

系统替用户做的事，也该按后果排个档，并且让用户一眼看得清，成本低的直接自动执行，中等的做完通知一声，成本高的先征得许可再动手。每一档怎么处理，用户可以一键设定。这个设计叫成本感知的行动委托。它跟工具审批、跟 15.3 的渐进自主讲的是同一件事，区别只在于，把系统内部的拦截规则翻译成了用户能直接读懂的偏好。

用户还得看得见智能体正在做什么、依据是什么、数据取自哪里。出错时给的归因要说人话，机票没订成，是因为日历助手查到那天有日程冲突，而不是丢过来一句“错误：预订未成功”。这条叫可观测性与来源可溯（observability and provenance），第 14 章的轨迹与归因是它的开发者版本。

置信度同样不该藏着。请求本身就含糊、证据又不充分的时候，与其硬凑一个看似确定的答复，不如摆出两个候选，各标各的可信程度，让用户自己挑，把最终决定权留在人这一侧。

用户随时都能暂停、纠正方向、再接着跑，进度一点不丢，可中断（interruptibility）指的就是这个要求，机制根基是 10.4 的取消信号加上这一节的暂停恢复。

这四条背后，还有一个更大的判断。这类系统的体验设计，正从界面设计转向委托式设计。用户不再一步一控，而是把开放式任务整段交给系统，界面要传达的东西也跟着变，从功能列表换成了能力边界、行动代价与干预点。四条里的可中断，第 16 章讲实时语音的打断处理时还会再提，那还是对可中断要求最高的一种场景。用户不等模型说完就插话，链路得当场把插话接进来，然后继续跑。

委托式设计落到派活的人手上，第一件事是把任务怎么派想清楚。可取的心态，是把对面的智能体当成一位能干但情况不熟的同事，目标是什么、背景在哪、有什么硬约束，讲清楚，步骤不必掰碎了一条条下命令。步骤捂在自己手里，模型能活动的范围就很窄；目标交代足了，路线留给它自己挑。手头有草稿时更别浪费，哪怕是半成品的想法也照样给出去，再补一句“这份可能有错”。有个东西可以对着反应，跟从一张白纸开始编，是两回事，前一种模型把力气花在核对与改进上，后一种才给编造留了空间。“可能有错”这个限定也别省，少了它，模型倾向于把草稿照单全收；有了它，草稿才是一份待评估的方案。

任务值得写成一页任务书，几栏固定，症状是什么，期望行为是什么，大概在哪个文件哪张表，本地有什么惯例，边界划到哪儿，成功条件是什么。前几栏给足信息，成功条件单独讲究，它只讲做完之后结果该长什么样，不规定怎么实现。信息不够用，明说停下来问，这正是澄清请求的用武之地。到了收工，这份任务书还有第二用，让智能体逐条对照成功条件汇报，哪条满足、哪条没满足、改动在哪些文件哪些位置，一并报出来。验收标准写下时是约束，收工时就成了检查表，缺的口子当场露出来，不留到生产里才发现。

15.2 把审批与澄清装进一条回路

四种形态里，工具审批与澄清请求用得最勤。这一节把它们装进同一条能跑的回路。场景还是第 4 章的运营助手，审批对象挑群发消息，正是第 4 章试一试里让读者自己加的那个工具。整条回路挂起等人、批准放行这两个回合，见图 15-2，代码与细节随后展开。

回路沿用第 4 章那一条，新增的东西只有两样。一个 GATED 集合，把要拦的工具列出来；一条 held 与 decisions 通道，把人的决定送回来。审批的代码直接加在原来的循环里，没有另搭一套系统。

"""工具审批与澄清请求装进同一条回路，python3 可直接运行。
先 pip install openai，并设好 DEEPSEEK_API_KEY 环境变量。"""

import json
import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="<DeepSeek 兼容端点，见官方文档>",
)
MODEL = "deepseek-v4-flash"

SYSTEM_PROMPT = """你是连锁品牌的运营助手。规则：
1. 回答或动手之前先判断信息是否够用，缺会改变结果的关键信息时，
   调用 ask_user 提问，一次只问一处，给出候选项；
2. get_daily_revenue 可直接使用；send_group_message 属于对外动作，
   系统会转人工审批；
3. 工具结果里的数字必须原样引用，不得改写或估算。"""

def get_daily_revenue(store_id: str, date: str) -> str:
    fake = {"ST001": 12850.5, "ST002": 9320.0, "ST003": 15704.2}
    if store_id not in fake:
        return json.dumps({"error": f"门店 {store_id} 不存在"}, ensure_ascii=False)
    return json.dumps(
        {"store_id": store_id, "date": date, "revenue_yuan": fake[store_id]},
        ensure_ascii=False,
    )

def send_group_message(group: str, text: str) -> str:
    # 真实实现对接企业 IM，这里只登记动作
    return json.dumps({"sent": True, "group": group}, ensure_ascii=False)

def def_tool(name: str, desc: str, props: dict, required: list) -> dict:
    return {"type": "function", "function": {
        "name": name, "description": desc,
        "parameters": {"type": "object", "properties": props,
                       "required": required},
    }}

TOOLS = [
    def_tool("get_daily_revenue", "查询指定门店指定日期的营业额，单位为元。",
             {"store_id": {"type": "string"}, "date": {"type": "string"}},
             ["store_id", "date"]),
    def_tool("send_group_message", "往指定运营群发送消息。",
             {"group": {"type": "string"}, "text": {"type": "string"}},
             ["group", "text"]),
    def_tool("ask_user", "缺关键信息时向用户提问，question 中给出候选项。",
             {"question": {"type": "string"}}, ["question"]),
]
EXECUTORS = {"get_daily_revenue": get_daily_revenue,
             "send_group_message": send_group_message}
GATED = {"send_group_message"}  # 对外动作一律过审批，判据在代码不在提示

def assistant_msg(msg) -> dict:
    """把 SDK 返回的消息转成最小字典，只留协议需要的字段。
    tool_calls 空时置 None，靠端点宽容；严格端点应整键剔除再发。"""
    return {
        "role": "assistant",
        "content": msg.content,
        "tool_calls": [
            {"id": c.id, "type": "function",
             "function": {"name": c.function.name,
                          "arguments": c.function.arguments}}
            for c in msg.tool_calls or []
        ] or None,
    }

def run_turn(session: dict, user_input: str | None,
             decisions: list[dict] | None = None) -> dict:
    """执行一轮。撞上审批或澄清即退出，状态全部留在 session 里。"""
    if user_input:
        session["messages"].append({"role": "user", "content": user_input})

    if decisions is not None:  # 决定按调用 id 回填；审批轮缺席视同驳回
        was_clarify = session.pop("awaiting", None) == "clarify"
        for call in session.pop("held"):
            d = next((x for x in decisions if x["id"] == call["id"]), {})
            if "answer" in d:                    # 澄清，回答当工具结果
                content = d["answer"]
            elif d.get("approve"):               # 批准，现在才执行
                content = EXECUTORS[call["name"]](**json.loads(call["args"]))
            elif was_clarify:    # 澄清轮里人没见过的门控调用，记暂缓不记驳回；
                                 # 替人伪造决定的事，下面正文专说
                content = "任务信息尚在澄清，本次调用未送审，请澄清后重新发起。"
            else:                # 审批轮缺席即驳回，白名单式批准
                content = "人工驳回本次操作，请改用其他方式完成任务。"
            session["messages"].append(
                {"role": "tool", "tool_call_id": call["id"], "content": content})

    for _ in range(6):  # 轮数上限，第 2 章的兜底纪律照旧
        resp = client.chat.completions.create(
            model=MODEL, messages=session["messages"], tools=TOOLS)
        msg = resp.choices[0].message
        session["messages"].append(assistant_msg(msg))
        if not msg.tool_calls:
            return {"status": "done", "reply": msg.content}

        held = []  # 本次拦下的调用，自动工具照常执行
        for call in msg.tool_calls:
            name = call.function.name
            if name in GATED or name == "ask_user":
                held.append({"id": call.id, "name": name,
                             "args": call.function.arguments})
            else:
                result = EXECUTORS[name](**json.loads(call.function.arguments))
                session["messages"].append(
                    {"role": "tool", "tool_call_id": call.id, "content": result})
        if held:
            session["held"] = held
            if any(c["name"] == "ask_user" for c in held):
                q = json.loads(next(c for c in held
                                    if c["name"] == "ask_user")["args"])
                session["awaiting"] = "clarify"  # 记下这一轮人只见到问题
                return {"status": "clarify", "question": q["question"]}
            return {"status": "pending_approval", "held": held}
    return {"status": "max_turns"}

if __name__ == "__main__":
    session = {"messages": [{"role": "system", "content": SYSTEM_PROMPT}]}

    out = run_turn(session, "对比 ST001 和 ST002 在 2026-08-24 的营业额，"
                            "结论发到华东大区运营群")
    print(out["status"], out.get("held"))
    # held 里的调用 id 送进审批界面，这里直接演示批准

    out = run_turn(session, None, decisions=[
        {"id": session["held"][0]["id"], "approve": True}])
    print(out)

这段代码有四处值得注意。GATED 常量装着审批的全部判据，工具名进了集合就拦，没进就放。第 10 章讲的规则式委派，落到执行器里不过是一行集合判断。

暂停发生时，自动工具早就执行完了，门控工具只是挂起来。执行过的消息进了历史，挂起的消息等决定回来再补。恢复的时候，每个挂起的 id 都得有交代，审批轮缺席一律按驳回处理。协议上，工具消息必须与调用请求逐条对应，漏一条，下一轮请求直接报错，白名单式批准顺带把这条协议约束也守住了。

ask_user 与审批共用同一条挂起与回填通道。人的回答写进历史的方式，跟工具结果完全一样，“人的输入就是消息”这句话到这儿成了字面事实。

第四处是个陷阱。模型在同一轮里既提问又发群消息时，这一轮会在 ask_user 上当场挂起等人，发送请求到不了送审那一步。人只看到问题，没看到发送请求，那次没送审的调用，回填时该记成什么？记人工驳回，等于替人伪造了一次决定，翻对话史还看不出任何破绽。这里真正记下的是暂缓。模型拿到澄清答复，重新发起发送，才走进正常的审批展示。安全组件放在确定的一侧，这一侧同样不能记一条从没发生过的决定。

顺着演示把 run_turn 的两次调用走一遍，整个来回就是图里这个样子。第一轮里 get_daily_revenue 是自动工具，当时就跑完；send_group_message 收进 held，返回的状态是 pending_approval。审批界面从 held 里拿出调用 id，等人点了批准，第二次 run_turn 带着 decisions 进来，发送这才执行，模型拿到结果给出最终答复。两次调用隔了多久并不重要，会话的完整状态始终写在 session 字典里，把它存进数据库，就是 15.5 说的状态外置。

这段代码跑起来后，两次 print 正好核对两处状态。第一行把状态和 held 一起打出来，状态停在 pending_approval，held 里那条 name 是 send_group_message，args 里的群名与文案都齐全，id 正是送进审批界面的凭据。ST001、ST002 两家的营业额查询不在 held 里，走的是自动工具，结果已经写进历史。第二行打的是 done 和模型的最终结论，里面的数字应当原样是 12850.5 与 9320.0。系统提示第三条要求原样引用，一旦出现改写或估算，就说明这条链路有环节出了岔子。

这套挂起恢复的机制不必回回从零写起。OpenAI Agents SDK 在工具上提供了 needs_approval 参数，运行一旦停下，挂起的调用会出现在结果对象的 interruptions 字段里，应用这边调用 state.approve 或 state.reject，运行就能接着走。

LangGraph 一侧的对应做法，是 interrupt 函数加上检查点恢复。整体骨架与手写版相同，标记挂在工具或节点上，状态外置，恢复由一次全新调用完成。至于检查点机制怎么运作、恢复时容易碰到哪些麻烦，都留到第 17 章 17.3 讲迁移成本时细讲。

在哪里拦，四种形态给了答案。而拦下来之后，人会批、会驳、会改参数，这些决定本身就是数据。哪类调用经常被人驳回、哪类澄清翻来覆去地出现，攒在一起，就是一份标出系统不可信位置的清单。

审批人这一侧同样有几件事要定。待审批队列积压了怎么办，批量批准怎么设计，挂起超时走什么流程，这些都得在产品层面定下来。批量怎么批，14.3 谈人工审批容量时给过一条现成思路，低风险的批量走抽检，高风险的才逐条过。审批标记是不是卡得太严，也有信号可观察。14.4 第十条给过经验值，审批通过率长期高于 95%，就该升一档、少拦一些。

发起任务等结果的人，还有个怎么等的问题。审批通过、任务失败、里程碑到了待确认，系统里每一次状态跳变都可能值得说一声，可谁的哪次跳变要提醒、走邮件还是即时消息，不该由系统替所有人定死。把通知做成状态跳变上的开关，用户自己挑关心的跳变，系统照配置推消息。有人只要“跑完”那一声，有人要步步都报，都随他。人不必隔一会儿回来刷一遍页面，挂起三天的任务也不怕忘。

这里还埋着一条最容易漏掉的风险。审批人自己同样站在攻击面上。中了间接提示注入的智能体，不会直白地说“删掉数据库”，它会讲“发现 400 条造成延迟的冗余历史记录，建议做一次定向清理来优化性能，点击批准即可继续”。这套说辞体面、专业、理由齐全，批准人眼前是一条说得通的运维建议，哪里像攻击。最主力的安全机制，就这么变成一道绕得过去的关卡。审批能拦下不可信的动作，可这份安全不是白来的。

15.3 渐进自主

渐进自主回答三个问题，放权靠什么作依据，放权的动作在哪几处配置上，收权由什么条件触发。13.4 结尾给过一道三档阶梯，只读起步、写操作带审批、小额退款带上限，那是安全止损角度的一句话版本，这一节把它扩成一套能运转的制度。

这条路线有自己的名字，叫渐进自主（progressive autonomy），起步时把行动能力卡得很紧，可靠性一项项验证过关之后，再逐步松开。光有名字还不够，还得三件东西配套。第一件是上下文安全界限，这道界限跟随行动的上下文走，全系统不统一处理，行动按风险分好级，每级配各自的安全协议。第二件是持续验证，定期评估决策模式，把潜在风险找出来。第三件是应急协议，需要时能立刻退回人工干预。

这三件事每一件都平常，起步时把行动能力收紧，过程中定期拿数字核一遍，出了异常能退回人工。可对实际运营智能体的团队来说，三件凑齐就是一个闭环，权限收得紧，效果用数字量得出来，出了问题也退得回去，哪一件缺了都转不起来。与它互补的是 Rule of Two 那道硬约束。不可信输入、敏感数据、改变状态或对外通信三条全占的会话必须引入人机协同，所以起步那一档天然就带着人。倒不是谁保守，起点是规则自己推出来的。

分级表是这套制度的主干。下面这张表把阶梯拉成五档，例子仍用第 4 章的运营助手。档位越高，人离得越远，每一档的放权条件与回退触发都逐行写明。

档位	自主范围	人留在哪	放权条件	回退触发
L0 影子运行	只读工具，产出只给内部评审	全部产出人工转交	首轮任务集跑通，无编造数据	评审发现编造
L1 只读服务	只读工具直接服务用户	抽样复核加监控	只读通过率连续稳定，恶意案例全拦	抽检驳回率超阈
L2 写操作带审批	白名单写工具，逐动作审批	审批队列	L1 持续达标，写操作驳回率低	单次重大误操作
L3 阈值内自主	低风险写操作直执行，超阈转审批	阈值与审计	审批日志证明该类动作可靠	阈值内出一次事故
L4 域内全自主	该任务类型全自主	审计加应急停止	长期多次全对，零重大事故	任何重大事故

放权的依据得落到数字上，第 12 章那套方法论在这儿兑现。常用的数字有三类。第一类是任务集通过率，正常案例与恶意案例收进同一个任务集，第 13 章攒下的攻击样本也一并入列。第二类是稳定性，看同一个任务跑多次是不是次次做对，第 12 章引过的 pass^k 指标，量的就是稳定性。第三类是线上抽样人工复核的驳回率，拿它度量真实流量上的质量漂移。

一种有依据的起步门槛是这样，连续两轮评测通过率不低于 95%，关键任务 pass^4 全对，抽检驳回率低于 5%。这三个数只是参考起点，真正的门槛得随业务风险定，退款场景的 95% 与问答场景的 95%，分量完全不一样。门槛往哪个方向定，还有一条不对称要放在心上。信任建起来难、毁掉容易，攒了半年的纪录一次就清零，所以门槛该照着“会被记住的那次失败”来设，而不是按平均情形。

数字以外，还有一类同样过硬的依据，就是审批日志的分布。某类调用一连一两个月没人驳回、也没人改过参数，它就成了下一个放权候选。驳回如果集中在某一类调用上，说明那类动作的提示或参数设计有问题，先修好，再谈放权。

数字决定放权的节奏，上下文安全界限处理的是同一套系统内部的差异。风险分级不算新概念，第 13 章的授权层已经按工具风险分过类。差别在于，这里把分级做成了显式协议，每一档配一套自己的校验强度。只读档的工具过一遍归属校验就行，写操作档叠上审批，凡是涉及钱与对外沟通的档，再加速率与金额双上限。

同一个会话内部也能混档。制度问答一路只读放行，话题转到群发，自动升到审批协议，会话不必为此拆开。这套分级平时看不见，到审计时全变成了现成的凭据。出事后回查，每个动作当时在哪一档、档内每道闸有没有放行，日志逐条都对得上。

切分还能顺着任务的阶段走。同一条修复类的任务，排查定位那一段只给读，动手修改那一段才放开写，进入验证又收回成只读，每一段只握着这一段要用的权限，任务从头到尾没有哪个时刻攥着全套能力。

团队里也是同一套用法，这里有现成的记录。一家大型 AI 公司十个团队采纳编码智能体的记录里，产品开发团队把工作切成两半。原型和外围功能走自动接受模式，自主循环负责写码、跑测试、迭代，工程师接手打磨前，先审那份完成约八成的方案。核心业务逻辑则走同步模式，提示词写得非常详尽，人实时盯在旁边。另一支管模型服务的团队里，没有机器学习背景的成员靠它读懂了模型专属的函数与设置，研究时间省下八成，过去一小时翻文档读论文的工作，现在十到二十分钟收工。数据科学团队的说法是，日常重构省出两到四倍时间。三段记录指向同一个分法，外围放开、核心收紧，档位跟着任务风险走。

这些记录讲的都是怎么放权，还有一道更基础的分野，说的是拿智能体做什么任务。一头是逐字符的内联补全，光标停在哪儿，建议就跟到哪儿，改一行、补半句，人始终握着键盘；另一头是整段委托，多步任务、多个文件，一次派出去，智能体自己规划自己跑。两头各有各的擅长，成本结构也完全不同，成熟团队最后都是混着用，连续的小改写交给补全，跨文件的结构性改动交给智能体。不必在两种尺度里二选一，混配本身就是稳定的终态。

档位按任务类型来切，切换还能再往下细一层，看当次决策的置信度。自主性控制一共有三条路。前两条是规则压过模型、模型压过规则，所谓压过，就是两边冲突时听谁的。第三条先估模型的输出置信度。一个直观做法是把同一道题采样几次，看几次答案的分歧有多大。分歧收得拢，说明模型拿得准；分歧散得开，就是模型没有把握。置信度估出来以后设一道阈值，高于阈值听模型的，达不到就退回预先写好的规则，必要时把人也叫进来。

这两者正好互补。档位制照历史统计放权，某类动作连续多轮通过率稳了，就升一档。置信度按当次状态收权，这一次模型自己都没把握，当场退回规则或人工，不必等统计漂移出现苗头。

置信度不是接口顺手就能返回的，得自己估。token 似然，也就是 14.5 用过的那个输出词元对数概率，加上同题多次采样的分歧度，都是常用的估计量，阈值还要用校准集调出来。所以它更适合接在关键动作前面当一道闸，而不是当全系统的默认开关。估与校准花多少力气，看动作的风险定。

放权放完，事情并没有完，持续验证得跟上。要求是定期评估决策模式、识别潜在安全风险，落到日常就两件事。一件是周度抽检，按第 12 章的节奏从生产轨迹里抽样，人工复核驳回率，看质量有没有漂移。另一件是决策模式审计，每季度来一遍，把放权后的调用集中拉出来看分布。驳回率、改参数的比率和超阈值转审批的比例，任何一项爬升都是该降档的预警。抽检发现的问题照老规矩回流，第 12 章的任务集照单全收。

放权具体动的是三处配置，回路代码一行都不用改。第一处是工具白名单扩容。每个档位各自绑一张工具清单，升档就是往清单里添一个工具，第 13 章最小权限的纪律就按档位落了地。

第二处是审批从全量改成按阈值走。L2 阶段所有写操作逐个审批，L3 阶段只审超过阈值的部分。阈值是金额、受众人数和不可逆程度这类业务参数，写死在授权层，要改就走上发布流程，模型没有商量的余地。为什么必须写死，13.2 那位投资人的案例就是教训，Replit 智能体动了生产数据库，完整经过那边讲过。事后平台补的防护是一个规划模式，在这个模式下，智能体无权向数据库发送 UPDATE 或 DELETE 查询。

第三处是自主范围标记。档位按任务类型预先标好，请求一进来先查标记，再据此装配工具清单与审批规则。同一套系统里，门店问答能跑到 L3，退款相关还停在 L0，两边互不干扰。

档位能配的不光是权限，成本也用同一套做法。免费层换小一号的模型，检索深度调浅；企业客户上最强型号，检索加深。配置跟着请求分层，权限与费用一起管住。配置长下面这样，纯标准库，拿到就能跑。

"""档位驱动的权限装配：升档只改配置，不改回路。"""

AUTONOMY_LEVELS = {
    "L1": {
        "tools": ["get_daily_revenue", "search_policy"],
        "approval": [],                                   # 无写工具，无可审批对象
    },
    "L2": {
        "tools": ["get_daily_revenue", "search_policy", "send_group_message"],
        "approval": [{"tool": "send_group_message"}],     # 逐调用审批
    },
    "L3": {
        "tools": ["get_daily_revenue", "search_policy", "send_group_message"],
        "approval": [{"tool": "send_group_message",
                      "unless": {"group_size_lte": 10}}],  # 小群直发，大群审批
    },
}

TASK_LEVELS = {"门店问答": "L1", "日报生成": "L2", "晨报速报": "L3"}

def assemble(task_type: str) -> dict:
    """请求进来先查档位，工具清单与审批规则由档位决定。"""
    level = AUTONOMY_LEVELS[TASK_LEVELS[task_type]]
    return {"tools": level["tools"], "approval_rules": level["approval"]}

if __name__ == "__main__":
    for task in TASK_LEVELS:
        print(task, assemble(task))

放权必须给自己留退路。应急协议的要求，是降级通道随时都能用。出了重大事故一票降档，白名单回退，第 10 章讲过的外部取消信号在这儿同样派得上用场，运维随时能把运行中的任务停掉。

一票降档得落实到配置上。档位标记回退、白名单收紧、审批规则恢复成逐个审批，这三步收进一个脚本，出事故时一条命令跑完，比半夜爬起来手工改配置可靠太多。降档记录跟放权记录一样留痕，谁批准的、依据哪轮评测、什么时候生效，审计时一条都少不了。

跳档的诱惑非常具体。demo 做得惊艳，业务在催，领导拍了板，这三条理由没有一条够格当放权依据。第 12 章开头那个教训放到这里照样成立。没有对照的改动是在赌，没有数字的放权同样是在赌，差别只在后者的赌注更大，输的时候直接落进真实世界里。

赌输到底长什么样，公开记录里写得很完整。有位实践者复盘过一场 33 天的自主交易实验，交给编码智能体一个 10 万美元的模拟盘，让它自主交易，不许任何人干预。开头就是教科书式的过度自信，第一天它就把七万五千美元投进高波动个股，这笔钱占组合四分之三的仓位；它还试过在六分钟内连发十六笔没有信息优势的快速交易。首日收跌 1.1%。

实践者还搭了四个智能体互相制衡。这套治理层级最后是怎么瓦解的，第 9 章交代过，顾问智能体把风险看得极重，CEO 智能体又太容易让步，层层审议的结构一步步萎缩，最终变成单一智能体，还过度保守，实践者把这套制衡整个放弃了。崩溃之前它也不是一事无成，第二个交易日确实拦下过一笔追涨，大约避掉一万美元的损失。可它拦得下这一笔交易，阻止不了结构层面一步步的退化。

第三天的事故，完全在智能体的预料之外。一种主流加密货币一个周末从八万七千美元滑到八万，智能体并没有直接碰它，可手里的空头 put 仓位跟加密市场高度相关，三天里亏掉 3.4%。这类资产与资产之间的结构性牵连，往往要等真金白银亏出去才暴露。适应期结束之后，组合一度冲到 120,431 美元，约三周涨了两成多。接着一家大型半导体公司财报不及预期，单日跌掉 15,147 美元，跌幅 13%，一周内组合回到 93,450 美元，峰谷回撤 22.4%。峰值、谷值和单日跌幅全都留在这条路径上，评估自主运行，只看终值远远不够。

33 天跑完，组合停在 107,648 美元，收益 7.6%，同期大盘是 4.52%，单看收益确实跑过了市场。偏偏这个结果不能当成放权的依据，最大单笔盈利 14,578 美元，最大单笔亏损 15,147 美元，两头几乎对称，7.6% 是从一条剧烈起伏的路径里挣出来的。实践者自己在复盘里也写明了，这个回报让人鼓舞，却不可信赖，不要拿真金白银去冒这个险。

拿智能体替自己下单的散户，可不止他一位。主流媒体关注过这群人，热闹开场之后，接着的是一连串亏损。运气和能力各占多少，光靠这 33 天分不出来。能分清的途径在第 12 章，对照、多轮、有基线的统计。一次漂亮的成绩，从来不能当作放权的凭据。

渐进自主这套档位与数字的纪律，还能从生产流量里搬出去，用在 CI 流水线上。让智能体当哨兵，每个提交过来都过目一遍，裁决交回流水线来做。好不好用，由两个实操点决定。第一个点，是裁决的输出格式。让模型交结构化的裁决标签，结论之外带上理由，流水线解析标签，决定放行还是拦下。别在模型写的长评论里裸搜关键词。评论里蹦出一个 critical 就触发拦截的规则，早晚误伤。模型讨论风险时会提到这个词，跟真把它判成 critical，是两回事。

第二个实操点是放权的节奏，一共分四步。第一步，哨兵的任务只是评论，把自己的意见讲出来，但绝不改动流水线的产物。跑得稳了就升黄牌，问题照标，但不拦。再往上才是红牌，判不过就拦下合并，同时必须留一个人工覆盖的口子，万一误判，人能放行。到最后一步才让它主动动手，自己提交修改。升级与否由数字说了算，不看过了多久，驳回率和误伤率都稳住了才往前走一档。渐进自主在 CI 里就是这么完整实现的。

真走到让它自己动手提交修改那一步，这条管道还得配上全自动的验证与回滚。每份候选改动先过评测，指标不过就自动退回上一版，不需要等人来处理；每一次自我修改都留下版本记录，改了什么、凭什么改、改完跑出什么成绩，事后逐条核得清。验证与回滚一旦还得靠人盯，自己动手改东西就算不上闭环，改进的速度全折在等人上。

档位表之外还藏着一档自主，管的是什么时候动。表里管的是单次任务给多大权限，可智能体多半仍是等人开口才动，想让它明天早上九点自己跑一遍全量回归，就得给它一件排程工具，登记触发时间加一句到点要办的事；到期的任务先排队，等智能体空闲了再作为一条新消息交付。工程上有三条边界要事先定死。交付语义取至少一次，进程如果在交付之后、记档之前退出，重启后同一件任务可能再来一遍，接任务的一侧要能幂等。停机不补跑，错过的时刻就放过，要补的记录自己存。定时回合与用户正在进行的回合互斥，不在对话中间插进来，需要交互确认的工具调用在定时回合里直接拒绝。还有个常被问到的问题，进程一关，调度是不是就停了？是。真要关机之后仍按时执行的，交给系统的 crontab 一类外部调度，别指望智能体自己承担。

15.4 部署形态

15.2 的执行器待在本地脚本里一切正常，可一放上服务器，三个新问题马上冒头，用户还等不等得起，进程能不能挺过重启，流量涨上来扩不扩得动。前两问决定任务怎么跑，是这一节的主角，选哪一种看两条，任务要跑多久、用户当时在不在场。第三问是放大多少份，下一节单独讲。

第一种形态是同步 API 服务（synchronous API serving），把执行器整个放进一个 HTTP 端点，请求进来、任务执行、答复返回，一次请求就是一次任务。借 FastAPI 或 Flask，几十行代码就能把 15.2 的 run_turn 变成服务，第 2 章起写下的代码一行都不用改。业界梳理智能体工程的技术栈时，为它专门留了一层，叫 Agent 托管与服务，做法是把智能体当作基础设施上的服务来部署，用 REST API 访问。

适用判据定得很硬。任务时长在秒级，用户在线等着，营业额问答、制度检索都属于这个形态。边界同样清楚。任务一旦超过几十秒，HTTP 连接、网关超时和用户耐心三件东西同时开始计时。把长任务放进同步端点，占住的是请求线程与连接，并发一高，先倒下的是服务。

呈现层这里只点一下，不展开讲。用户在线等待答复时，回答常常是一段一段生成、一段一段推出来的。SSE 和 WebSocket 该怎么选、聊天界面与前端组件怎么搭，这些都属于呈现层工程，在本书“原生 API 与协议为主线”划定的边界之外。真想上手，Streamlit、Gradio 这类可视化交互工具是现成的材料，出处列在本章参考资料里。

边界归边界，这对选型的判据只有一条，看谁需要主动开口。回答一段一段推给浏览器，方向只有服务端到客户端一头，SSE 就够用，它跑在普通 HTTP 上，代理、负载均衡和鉴权照常工作，断线重连也是浏览器内置的能力。一旦客户端也要随时发话，就换 WebSocket，一条升级成双向的连接，两头都能主动推，16.2 实时语音正是这个样子，麦克风的音频要持续上行，用户插话要当场递进去。第 5 章 MCP 那边的 SSE 管的是服务器单向推消息，语境不同，取舍的道理是同一条。

第二种形态是长任务 worker（long-running worker）。任务先排队，worker 进程在后台一份份地消费，进度存进检查点，全部跑完再回调或通知。Celery、RQ 和 arq 都是拿来就能用的队列方案。队列跟执行循环在哪儿对接？答案就是第 8 章的会话，任务消息里带上 session_id，worker 取出对应会话接着跑。

这一形态的适用条件，跟同步形态正好错开互补，那些要跑几分钟到几小时的批量任务，比如凌晨的全门店日报、第 6 章的知识库重建和第 12 章的任务集回归评测，全都归它管。

带着审批的长任务，天生就归这一形态。15.1 讲的暂停恢复搁到生产环境，呈现出来的正是这样，执行进程退出去，状态落进库，审批隔了几天才回来，任何一个空闲的 worker 拾起会话接着干。

这类需求，协议层很早就把它标准化了。MCP 在 2026-07-28 那版规范里把 Tasks 列为官方扩展，异步长任务的执行、轮询查询、中途输入和可持久化句柄都在覆盖范围里。A2A 协议 1.0 的任务生命周期则备了一个专用状态 INPUT_REQUIRED，智能体要等人工补输入时，就停在这个状态上。跨系统协作里，等人已经成了头等需求，自建系统没有理由不照着做。

这两种服务形态并不对立，生产系统里往往同时存在。怎么分派，判断标准始终只有两条，任务要跑多久，人是否在场。人在屏幕前、几秒就能出结果的，走同步端点；人已经走开、任务要几分钟以上的，进队列，跑完了靠回调或 IM 通知把人叫回来。同一个产品里，店长随口问一句的问答，和凌晨的全店日报，走的是各自不同的通道。前台入口是同一个，后台按任务类型分流，15.6 的案例就是这么运转的。

两种形态之间还有一档更细的异步，发生在单次会话内部。装依赖、跑全量测试和做大构建，这类一跑几分钟的工具调用，让回路干等是白费，可整段对话又没到该丢进队列的程度。现成的做法是让模型在工具参数里显式要求后台执行，这次调用立刻回一份占位结果，附一个任务编号，回路继续去干不依赖它的任务；已经完成的后台结果，等下一轮开始前以一条独立通知进对话。协议的配对纪律不破，一次调用仍然只有一份正式结果，占位与通知各算各的事件。分水岭在谁等结果，长任务 worker 跑完通知的是人，环内后台任务等的是下一轮。这项机制在编码智能体里已经是标配，出处见本章参考资料。

再往前一步，把外部发生的事接进正在运行的会话，正在变成模型接口自己的原生能力。环内后台任务靠协议定义占位与通知，接口层则刚开始原生支持中途递入。OpenAI 的 Responses API 已把最基础的一种做成了官方能力，叫中途转向（mid-turn steering），一次回复还在生成，新的用户消息就能从连接上递进去，模型当场调整方向，已经发出去的输出不会改写；碰上正在等工具结果的当口，递进来的消息先排队，结果回来了再续上。更深的一步，工具还没返回就让模型继续推理，模型接口这一层，各个模型服务提供商的口径尚不统一，眼下主要在协议层，MCP 的 Tasks 扩展先把它定成了标准。截至 2026 年 9 月，各家厂商进度不一，动手接之前，以当期官方文档为准。

接口层的异步还有一条打折的途径，叫离线批量（batch API）。把一批互不依赖的请求攒成一个文件提交，厂商在承诺的时限内整批跑完、整批送回，收费按折扣价计，各家厂商折多少、时限多长，照当期定价页与文档核对。适用判据就两条，请求彼此独立，结果不急着要。它跟环内后台任务不是一回事，批量省的是单价，环内省的是等待。15.6 那份凌晨两点的全门店日报正是这类任务的典型，两百来个门店各自成单、互不依赖，天亮前给到就行。

写成代码看下面这个骨架，它只管部署形态本身，演示同步端点和审批恢复端点怎样共用同一份外置会话；可观测性、成本核算和故障恢复这些命题，主体在第 14 章。模型调用与工具实现沿用 15.2，定义这里不再重复。

"""示意骨架：同步 API 加异步审批恢复的部署形态。
pip install fastapi uvicorn 后可 uvicorn approval_api:app 起服务；
run_turn 与 SYSTEM_PROMPT 沿用 15.2 的定义，整段拼进本文件，此处从略。"""

import json
import uuid
from pathlib import Path

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()
STORE = Path("./agent-sessions")  # 生产换成 Redis 或数据库，机制不变
STORE.mkdir(exist_ok=True)

class Ask(BaseModel):
    question: str
    session_id: str | None = None

class Decision(BaseModel):
    call_id: str
    approve: bool

def load(session_id: str) -> dict | None:
    path = STORE / f"{session_id}.json"
    return json.loads(path.read_text(encoding="utf-8")) if path.exists() else None

def save(session_id: str, session: dict) -> None:
    path = STORE / f"{session_id}.json"
    path.write_text(json.dumps(session, ensure_ascii=False), encoding="utf-8")

@app.post("/agent")
def ask(body: Ask) -> dict:
    session_id = body.session_id or uuid.uuid4().hex[:12]
    session = load(session_id) or {"messages": [{"role": "system", "content": SYSTEM_PROMPT}]}
    out = run_turn(session, body.question)      # 15.2 的执行器，原样复用
    save(session_id, session)                   # 状态外置，实例不持有记忆
    return {"session_id": session_id, **out}

@app.post("/agent/{session_id}/approve")
def approve(session_id: str, body: Decision) -> dict:
    session = load(session_id)  # 任何一台实例都能恢复，不需要会话粘性
    out = run_turn(session, None,
                   decisions=[{"id": body.call_id, "approve": body.approve}])
    save(session_id, session)
    return out

还有两个生产细节，说不上属于哪种形态，可每种形态都得过它们这一关。第一个是幂等。第 4 章讲工具设计时给过定义，同一个操作，执行一次和反复执行多次，结果应该一样。worker 重试、网络把同一请求发两遍、用户手滑点了两下，这些都会让同一个任务跑两遍。只读工具多跑一遍没有关系，群消息发出两遍就是事故。应对办法是给每次工具执行记一条执行记录，用调用 id 当键，重试时先查记录再动手；第 8 章的草稿区正好拿来放这份记录。

再一个是超时与取消。第 10 章讲过的优雅取消，部署层也得照着做，停止信号一进来，运行就停在当前这一步，状态写入库，轨迹与用量记录照常打包。用户中途改了主意，到手的不是做了一半的残次品，而是一份记录完整的阶段性交付。

形态上还有一种极端做法，顺带交代一句，连后端都不设，执行器整个跑在用户浏览器里，页面直连模型接口。教学演示、想在小圈子里传播的交互样例，这条路的零运维是真有价值，一个链接发出去就能跑。可密钥只要进了页面就等于公开，第 13 章的密钥治理在那儿没有半点余地。生产的答案，仍然是上面这些带后端的形态。

15.5 水平扩展与变更验证

水平扩展（horizontal scaling）是同步与异步两种形态共用的放大器，前提只有一条，实例必须无状态。状态放哪儿，第 8 章已经回答过，会话外置到文件、数据库或 Redis，实例只负责计算。

无状态带来四条收益。任何服务器都能接恢复请求，等待期间不占连接，崩溃不丢会话，负载均衡不需要会话粘性。前两条 15.1 讲过，后两条在扩容时兑现。加实例不必迁移会话，倒下一台，别的实例照常接单。

怎么扩，得分形态看。同步形态加实例，前面挂上负载均衡；异步形态加消费者，队列天然起着缓冲作用。峰谷明显的业务，还要配上背压。队列长度超限就拒绝新任务，提示稍后再来，比让任务一直排到超时干净得多。

一旦是多租户形态，还会多出一类共享问题。多个团队共用同一批智能体服务，某个团队占掉过多资源，其他团队的性能与可靠性跟着下降，这就是吵闹邻居（noisy neighbor）问题。这个问题归平台团队监控和缓解，常规手段有三条。速率限制管单个租户的请求速率，资源配额管资源占比，优先级机制管拥挤时的服务次序。

挤占之外，共享还有一份数据的划分要做。多个租户共用同一批智能体与 MCP 服务，数据、计量和日志这三个都得按租户划开，请求带着租户标识进来，会话和记忆按租户分键，费用按租户各出各的，日志里也别把甲家的查询混进乙家的记录。检索这一层有两条现成做法，按租户物理拆库，或者共用一个库、按命名空间分片，路由在请求那一层做，租户标识一路传到检索调用为止。

共享到什么程度，第一道岔路是产品跑在谁的云里。自家运营多租户 SaaS，一套实例服务所有客户，升级一次全量生效，运维集中；另一条路是把智能体部署进客户自己的云账号，占一块锁定的专属资源组，数据不出客户的环境。金融、医疗这类把数据驻留当硬要求的行业，第二条路成本虽高，却常常是唯一卖得动的形态。计费跟着分岔，按用量付费波动大，预算难做，于是厂商备了承诺容量一类的方式，按月付固定费用，换一段预配好的吞吐，用满用不满都归自己。是否划算，得拿自家流量的峰谷去核。

智能体进了平台，上架只是开始。谁能用，靠激活来管：可以按人预装，好用的置顶推广，出了事的停用下架，升级要走版本批准。这套日常动作归平台运营管，每一下都得留痕，道理跟 15.3 的放权记录一样，治理不是发布那一刻的事，是上架之后天天做的事。

到底扩到多少才算够，容量规划要先从预期会有多少人采纳算起。最容易犯的错，是把用户增长想成一条平滑上升的曲线。真实的采纳节奏通常更接近逻辑斯谛曲线，画出来呈 S 形，开头慢，中段指数式往上蹿，接近饱和后涨势放缓、慢慢走平。真逼近饱和时，实际数据还会偏离这条理想曲线，早期流失和使用疲劳先把人数拉下一截，随后老用户回流与后期采纳又补回来，最后在一个核心规模附近稳住。

发布当天本身就会冒出一波峰值，起步容量至少得按预期的最初采纳规模来准备，不能按日均负载来定。算吞吐有个口径，全员每分钟 token，也就是所有用户挤在同一分钟窗口里总共消耗的 token 数。按这个口径核容量，比照着用户数量粗估更接近现实，毕竟一场对话和十场对话烧掉的 token 差着量级。

真正的上限常常不在自家服务上，而在模型厂商的并发与速率配额。扩容之前先把配额核对一遍。我见过实例全起好、扩容也做完了的团队，最后卡在厂商的速率配额上，提额申请来回等了好几天。第 14 章的成本核算只算到 token，速率配额得自己去查。

扩多少、配额查完，剩下的问题是这些进程装在什么里交付。现在的常规答案是容器。把一个智能体连同它的依赖打进一个镜像，升级就是换镜像，回滚就是换回旧镜像，扩容就是多起几份，跟本章反复强调的无状态要求正好对上。多智能体系统在这里有个现成的好处，第 10 章的编排图本来就把各角色画成了独立的服务，编排文件里一个角色一个服务，几行声明就能把整条拓扑在本地拉起来，前端智能体把其余角色当工具调，也接得上第 5 章 MCP 服务器的方式。一容器一智能体是常用的切分方式，整条工作流打包成一份也行，判据还是那一条，哪个角色要独立扩缩、独立换版，哪个就单独成容器。镜像怎么生成、命令怎么写，查 Docker 官方文档就好；生成的镜像进生产前，照例要人工评估一遍再裁剪。

拆多细有判据，什么时候才值得拆，是另一道顺序题。系统先以单体起步，一个进程装下全部逻辑，把业务价值验证了再说，推理、工具交互和护栏这些东西，在受控的单体里磨，比在分布式环境里磨便宜。等三个信号冒头再动手拆，用户量涨到单体处理不过来，专门化的智能体攒过了三四个，长跑的异步任务多到一份简单脚本照顾不来。这些触发条件最好提前写下来，把“要不要拆”从一次被动的恐慌，变成一个规划好的事件。拆的时候第一件事不是画服务边界，是把状态先从进程里搬出去，前面讲的状态外置正是拆分的地基。顺序要是反了，网络故障、部署编排和链路追踪，分布式的代价件件提前落到头上，价值还没验证就先背上。

变更上线前的验证有三道，第一道在离线，后两道在线上。离线这道做的是模拟验证，一条真实流量都不碰；影子测试与金丝雀跟在后面，拿真实流量跑。三道各管一段，离线模拟看行为对不对，影子测试看新旧两版在真实流量面前差多少，金丝雀看小流量真切换之后指标稳不稳。顺序不能颠倒，越往后离生产越近，代价也越大，能在离线挡住的问题，不该留到线上去发现。

离线这道用的零件，前面的章节都造过，要做的事情是拼装。第 12 章的 τ-bench 造过模拟用户，一个由模型扮演的用户，跟带工具的智能体多轮对话；第 14 章 14.6 的可复现仿真备过模拟环境，工具和数据收进同一套接口，要它超时它就超时，要它报错它就报错。那层把模型也换成了桩，同一份输入永远走出同一条轨迹，测的是编排逻辑；上线前要验的是行为，模型必须是真的，换掉的只能是它周围的世界。真智能体、模拟环境、模拟用户，三样拼起来就是这道验证：工具的失败可以按剧本发生，业务状态放在模拟库里，跑错了没有任何真实后果。第 14 章的混沌工程讲究给故障圈爆炸半径，这里的故障本来就注在模拟环境里，伤不着真实系统，圈半径这一步天然就省了。场景跑完，环境状态跟整条轨迹一起存档，随时能原样重放；改一版提示词再跑一遍，两遍轨迹摆在一起，改动影响了哪几步，一眼对得出来。

连锁品牌的周报智能体换版之前，团队在离线搭了这样一套场景：42 家店的营业额放进模拟库，取数接口第三次调用注入超时；模拟用户扮运营同事，开口就把门店编号说成隔壁店的，成稿之后又变卦，要求把竞对数据整段删掉；群发工具指向模拟测试群，文案发得再错，真实的运营群里一个字都不会出现。跑完留下完整轨迹，这份轨迹就是上线评审要看的证据：注入的超时接住了没有，智能体是重试了，还是拿旧数凑数；编号对不上，它是停下来问人，还是拿错号硬算；变卦之后稿子改干净了没有，删掉的数字有没有在别处再冒出来。评审会上过的是这份轨迹，一句“测过了”，顶不上一遍能回看的执行记录。

离线跑通了，还不等于能上线。模拟用户带着第 12 章说过的老毛病，名字叫过分配合，什么都顺着智能体来，真实用户当场就会纠正的失误，它一件都没拦下，治理的三招原样搬过来就能用。更根本的短板在模拟本身，场景是团队设计的，故障是团队设想的，设想之外的用户问法、没料到的连锁反应，模拟一概测不到，这部分只有真实流量能给答案。所以三道验证是一整个序列，一关过了才走下一关。

线上这两道怎么走？新旧两路并行，拆成两步走。

要过安全关的变更不止扩容一桩，版本升级、更换模型同样在列。验证的做法仍是这两路并行，用真实查询来跑。第一步是影子测试（shadow testing），新版本在后台悄悄处理同一批请求，结果只记录不生效，用户那边看到的始终是旧版本的输出。对比数据攒得差不多，再把一小部分流量切给新版本，这一步叫金丝雀测试（canary testing）。比对的指标必须是业务结果，两路输出看起来像不像说明不了问题。任务集通过率、抽检驳回率这类数字，比文本相似度更能判断新版本是变好还是变坏。金丝雀的收尾就两种，指标稳住了，把流量逐步放大到全量；指标坏了，切回旧版本，改完再验一轮。

两路并行的代价很直接，推理成本翻倍，每一个查询都要把模型跑两遍。因此影子测试必须圈定时间窗口，挑有代表性的时段，跑完就撤，不能一直挂着。至于什么时候值得触发一轮这样的验证，有四个信号，任务集分数连续下滑，更便宜的模型在影子测试里表现不相上下，厂商公告老模型即将退役，路线图上的能力当前模型不具备。选哪个模型是持续性的运营决策，不是定一次就完事。

影子验证管的是换上去的版本好不好，另一头的威胁是跑着跑着慢慢变差，用户问法迁移、知识陈旧，线上质量一点点往下漂。真到了要靠再训练救回的地步，办法还是同一套，再训练出来的新版本先进影子跟线上版本对跑，数字过关了才切换。再训练永远配着再验证，这两步任何时候都不能只做一步。

15.6 一个 demo 的生产化改造全记录

这一节记录连锁品牌线从周末 demo 到生产上线的完整改造，六道关卡各要动什么、留下什么，逐关走一遍。起点是三月一个周五下午的 demo，运营的同事随手敲了一句话，三家门店昨天的营业额、相互对比和结论几秒钟就出来了；换一个人问跨区支援住宿报销的上限，制度问答助手把条款原文连同编号一并给出来。演示效果很好，出结论又快，总监当场定了，四周后上线，服务全国门店。

等工程师把手头的代码翻过一遍，盘点出来的却是另一张清单，营业额来自写死的字典，会话状态存在脚本内存里，API 密钥就放在环境变量中，没有审计，群发工具根本没有做权限检查，任务集也只是演示前临时挑的五句话。这张清单正是本节的主线。从周末 demo 走到生产系统的六道关卡，都沿着这条主线铺开。需要说明的是，案例为教学构造，时间线与数字都是虚构场景里的工程记录，机制则逐条都有出处。

第一关在工具与权限上，写死的字典换成了真实数据服务，门店营业额接口补上归属校验。大区运营只能查到本区门店，判断依据是会话身份，校验放在服务端，不靠模型自觉。第 13 章的纪律在这里原样执行。

工具清单也随之重排。只读的查询与制度检索直接放行，send_group_message 按 Rule of Two 归为对外动作，挂到 15.2 那道审批门上。第 4 章试一试让读者自己加的群发工具，此刻以带审批的正式工具身份重新上线，参数比那时多了一个群名，发给哪个群由调用时指定。

权限设计文档也同步归档，工具清单、每把凭据的用途和出口白名单，这三张清单一齐进了版本库。密钥从环境变量搬进密钥管理服务，每条凭据只授权给一种用途。第 13 章那三张清单，到这里才第一次填满真实内容。

第二关是状态与知识。会话状态从脚本内存搬进了数据库，审批挂得最久的一次前后跨了两天，周日晚提交的群发申请直到周一早上才批下来，恢复执行时上下文原样接续，第 8 章的检查点机制第一次在生产里显出威力。知识库这条线按第 6 章的质量工程补齐，制度改版的增量同步设成定时任务，生效日期写进元数据，作废条款进不了检索结果，检索质量则照命中率和 MRR（平均倒数排名，6.4 的指标）各立一条基线。

第三关最耗时间，就是评测。任务集从三个渠道一点点攒起来，门店员工的真实问法采样后做了脱敏，边界输入靠手工构造，超范围请求则照着第 13 章的样本风格写。攒任务集从第一关就开始了，贯穿全程，边改造边积累，两个月收到一百四十条。每条都配一张案例卡，输入、期望行为和来源日期，一项不缺。

打分这一层，按第 12 章的规矩配了 LLM 裁判。分档定义写死在裁判提示里，先给理由后给分数。上岗之前拿三十条人工结果对过一致率，才正式启用。

首轮跑分并不理想，端到端通过率只有 71%，检索命中率 82%，错误最集中的两类是日期口径理解错、跨条款汇总漏项。三轮修复各有各的着落，系统提示里补上日期口径的定义，切分参数按条款重新切，跨条款问题换成两跳检索。到第三轮，数字站上 94% 和 96%，恶意案例在授权层就全部拦下。

上线门槛是照着业务风险和总监商定的，定在 94%。15.3 里说过，那三个数字只是起点。上线评审的核心材料，就是这两张分数表，评审会上听不到一句凭印象的话。评测驱动开发在第 12 章提出，这里算是直接兑现，成功标准动工前就谈妥了，此刻只需对着分数表逐项核对。

第四关是部署怎么安排，问答请求挂在同步 API 上，四个实例排在负载均衡后面，每天两千次问答都走这条路。日报这类批量任务则交给 worker 队列，凌晨两点开工，把全部门店跑一遍，任务最多时两百个挤在队列里，跑完了用回调收尾。审批恢复与它们共用同一个会话库，哪台实例接手，全由负载均衡决定。

上线刚两周就赶上一次实例崩溃重启，正在进行的会话一个都没丢。无状态设计是否值得，平时论证再多，都不如这一场事故来得有说服力。又过了一周，worker 一次网络重试差一点把日报跑完的回调通知发上两遍，执行记录把第二遍拦了下来，15.4 那条幂等设计当场见效。自此工具执行前先查记录，写进了团队自己的部署清单。

第五关是人机协同怎么运营。上线档位先定在 L1，只开只读服务，群发一律不做。四周后做了一次评审，只读通过率连续保持稳定，抽检驳回率也在门槛之内，于是升到 L2。群发开始带审批，审批队列摆在值班运营的工作台上，约定两小时内响应，超时自动升级给主管。审批本身，也得有人守着。

又过六周，审批日志里的分布开始分化。小群速报这类调用没人驳回、也没人改过参数。大区群播报仍有三成被驳回，原因是文案里常夹带没核实的推断。

于是放权拆成两半，晨报速报升到 L3，十人以下的督导群可以直发；大区群播报留在 L2，审批的对象从动作上移到稿子本身。编辑流程到这里就变成了人机协同里的里程碑确认，智能体出稿，人改稿，批准之后才发送，驳回意见同步流进第 12 章的任务集。

第一次回退发生在七月，也是至今唯一的一次。当时一家新开门店的编号还没进库，智能体把查无此店误报成数据异常，触发了降档，持续一周。边界案例补进任务集之后，系统才恢复正常。

五道关卡走完还剩一道，这一道不在工程内部，而在监管。智能体对外发出去的内容，本身就是合规的监管对象。这一侧要做的事有三件。AI 生成的内容要打上显式标记；来源与数据背景要如实披露；还要附一份负责任使用指南，提醒使用者自己核查关键事实。

放到中文生产环境里，这些就不只是建议了，而是硬性要求。2025 年 3 月，国家网信办等四部门联合公布《人工智能生成合成内容标识办法》，同年 9 月 1 日施行，配套的强制性国家标准 GB 45438-2025 也在同一天生效。办法管五类内容，文本、图片、音频、视频和虚拟场景。标识分成两层，一层是用户能直接看到的显式标识，另一层是写进元数据的隐式标识。生成服务的提供者和内容的传播平台，分别承担各自的义务。

把办法落回这家连锁品牌，面向顾客的客服回复、公众号物料，确实都在它的适用范围里。对外文案的落款注明由智能体生成，物料走平台侧的标识能力发布，智能体回复顾客的模板里也带上生成来源的说明。至于内部运营群的日报速报，哪怕从严解释也暂不适用，团队还是统一加了智能体署名。加这一行落款几乎不花成本，换回的是整条可追溯链路。

13.4 那份伦理清单管的是行为侧，上线前已经查过一遍；这一道管的是产出侧。原则很直白，客服回复、公众号物料和内部群的日报，每一样产出都配上标识，漏掉哪一样都算没做。

顺着责任这条线还有一个名字值得辨一辨，免得张冠李戴。训练侧有一种做法，先给模型立一份成文的原则清单，让它照着原则对自己的回答先批评、再修订，分两个阶段练下来，模型的行事方式向这份清单收敛，这套训练法叫 宪法式 AI（Constitutional AI）。常有人把系统提示称作智能体的宪法，那说的是运行时贴在提示里的规矩；训练法里的原则作用在权重上，改的是模型出厂时的样子。名字相近，实际差着一整条生产线，读到“模型经成文原则训练”这类宣传时，别把它跟自家系统提示里的规范当成一回事。

把这几道关卡串在一起回看，真正耗时的部分没有一关出在模型技术上。权限、状态、评测、部署和放权，每一项都是工程设计和人的制度。

demo 一个下午就跑通了，生产化却整整走了十九周。光是评测四周、权限与审批三周和部署两周这三项，加起来就九周，才攒出上线的底气。总监当初说的四周，实际只够打完权限那一关。上线后又花十周，把 L1 到 L3 的拆分放权走完。时间几乎都投在建立信任上。

这个分配比例谈不上普适，有普适性的是它的构成，大头始终是建立信任的工程与制度。

上线满三个月，回头再看，接住的问答里，只读类占了九成，剩下的一成走完审批才发进群。15.4 讲的两种服务形态，在这里各找到各的位置，谁也没挤掉谁。

全自主是终点，不是起点，落到这家连锁品牌的案例上，就是第 2 章那个查快递的 while 循环头一回真正走进生产，关卡一道接一道地过，档位一档接一档地放。

本章小结

• 拦在哪里，15.1 给四种形态。工具审批拦单个动作，判据写在工具标记上、执行之前拦；澄清请求拦任务理解，缺的信息先问回来；里程碑确认拦阶段，先批方案、再验节点；暂停恢复是前三种形态的地基，状态外置，跨进程、跨天数照样续跑。
• 用户侧四条 UX 原则，能力发现、成本感知的行动委托、可观测性与来源可溯、可中断。
• 15.2 把审批与澄清装成一条回路。判据收在 GATED 集合，放在代码一侧，不指望提示词管住模型；人的决定经 held 与 decisions 通道回填；缺席视同驳回（白名单式批准）；同轮提问加发送时，没送审的调用记暂缓、不记驳回。
• 15.3 渐进自主。五档分级表（L0 影子运行到 L4 域内全自主），放权依据是任务集通过率、pass^k、抽检驳回率加审批日志分布，回退一票降档；放权只动三处配置（工具白名单、审批阈值和自主范围标记），回路代码不改。
• 15.4 部署形态。秒级出结果、人在场，走同步 API；分钟到小时、人走开，进 worker 队列；一批互不依赖、不急着要的，走离线批量换折扣。幂等与优雅取消，每种形态都得过。
• 15.5 水平扩展与变更验证。无状态加状态外置是横向扩容的前提；容量按全员每分钟 token 核，扩容前先查厂商速率配额；变更验证走三道，先离线模拟（真智能体配模拟环境与模拟用户，比对终态判分，轨迹存档可重放），再影子测试、后金丝雀，线上比对业务指标而非文本相似度；再训练永远配着再验证。
• 15.6 连锁品牌线从 demo 到生产走了十九周，时间大头花在权限、状态、评测、部署和放权这些工程与制度上，没有一关出在模型技术上。

第五部分到这里收尾。评测给出判断依据，安全划出底线，运维让运行状态看得见，人机协同安排好人在系统里的位置，四样齐备，智能体才算进了生产。

参考资料

• LangChain 官方文档 Human-in-the-loop（interrupt 函数、带恢复值的继续调用、检查点器与 thread_id、恢复时节点从头重跑），https://docs.langchain.com/oss/python/langgraph/human-in-the-loop ，核实于 2026-08。
• OpenAI Agents SDK 官方文档 Tools（needs_approval 参数、interruptions 挂起清单、state.approve 与 state.reject），https://openai.github.io/openai-agents-python/tools/ ，核实于 2026-08。
• OpenAI 官方文档 Mid-turn steering（Responses API 官方能力：回复运行期间递入新的用户输入、模型当场调整方向、已发出的输出不改写、等待工具结果期间递入内容排队；经 WebSocket 连接使用，支持范围以当期文档为准），https://developers.openai.com/api/docs/guides/steering ，核实于 2026-09-16。
• MCP 官方规范站（2026-07-28 版，Tasks 官方扩展覆盖异步长任务、轮询、中途输入与持久句柄），https://modelcontextprotocol.io/specification/ ，核实于 2026-08。
• A2A 协议官方规范 1.0（任务生命周期含 INPUT_REQUIRED 状态，指智能体需人补输入），https://a2a-protocol.org/latest/specification/ ，核实于 2026-08。
• OpenAI Batch API 官方指南（请求攒成 jsonl 文件上传、创建批处理作业、查询状态、取回结果；比同步接口便宜 50%，完成窗口 24 小时，独立限流池），https://platform.openai.com/docs/guides/batch ，核实于 2026-09-17。
• 《Build an AI Agent (From Scratch)》（Manning MEAP V3，2026）第 6 章（requires_confirmation 与提示消息模板、白名单式批准、缺席视同驳回、改参批准、执行前拦截）。见 txt-ref-zh/build-ai-agent-from-scratch/。
• 《Designing Multi-Agent Systems》（2025）第 4 章（approval_mode 标记、无状态退出与恢复、CLARIFICATION NEEDED 约定、人的输入当消息、无状态四条收益）、第 3 章（四条 UX 原则：能力发现、成本感知的行动委托、可观测性与来源可溯、可中断；委托式设计；交互式与离线场景）、第 8 章（呈现层工程：SSE 与 WebSocket 选型、聊天界面与前端组件，可视化交互入门材料）。见 txt-ref-zh/designing-multi-agent-systems/。
• Dell'Acqua et al., Navigating the Jagged Technological Frontier（哈佛商学院工作论文 2023，SSRN 4573321，后刊于 Organization Science，DOI 10.1287/orsc.2025.21838），参差的前沿（jagged frontier）提法出处，https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4573321 ，核实于 2026-08-28；出版版开放获取 PDF（摘要与提法全文直核）https://www.hbs.edu/ris/Publication Files/dell-acqua-et-al-2026-navigating-the-jagged-technological-frontier_5c589c8c-fbb5-458f-b285-c944746cd717.pdf ，核实于 2026-08-29。
• 《构建 Agentic AI 系统》第 8 章（信任机制：AI 生成内容显式标记、来源披露、负责任使用指南、输出不确定性的多方案带置信度呈现，见 txt-ref/构建AgenticAI系统/06-第8章 构建生成式AI系统的信任.txt）、第 9 章（渐进自主、上下文安全界限、持续验证、应急协议；该章内容收录于同一文件后半）。
• 国家网信办等四部门《人工智能生成合成内容标识办法》（2025 年 3 月公布、2025 年 9 月 1 日施行）及配套强制性国家标准 GB 45438-2025《网络安全技术 人工智能生成合成内容标识方法》（同日施行，显式与隐式标识、五类内容形态），https://www.cac.gov.cn/ ，核实于 2026-08。
• 《AI Agent 开发实战》第 6 章（Agent 工程化技术栈、Agent 托管与服务经 REST API 访问的方向；6.3 可视化交互：Streamlit 入门）。见 txt-ref/ai-agent开发实战/。
• 《The Agentic Enterprise》（2026）前言（自主性控制三路线：规则凌驾模型、模型凌驾规则、置信度阈值切换，含同一输入输出范围估计置信度的办法）。见 txt-ref-zh/agentic-enterprise/。
• 《Patterns for Building AI Agents》（Sam Bhagwat、Michelle Gienow，O'Reilly 2025）第 3 章 Dynamic Agents（动态智能体：配置随请求分层，支持力度按用户层伸缩，检索深度 topK 与模型档位随层配给，权限与成本同一套做法）、第 20 章（Replit 智能体口头保证不动生产数据库而实改，平台事后补规划模式，该模式下无权向数据库发送 UPDATE 与 DELETE 查询）。见 txt-ref-zh/patterns-for-building-ai-agents/。
• 《AI Agents: The Definitive Guide》（Nicole Koenigstein，O'Reilly 2026）第 12 章（威胁建模中的社会工程与人在回路：被攻陷智能体用推理能力操纵批准动作的人，400 条冗余记录的定向清理话术示例，最主要安全机制变成可绕过的关卡）。译文见 txt-ref-zh/ai-agents-definitive-guide/。
• Jake Nesler, I Gave Claude Code $100K to Trade With in the Last Month — and Beat the Market（一位实践者对 33 天自主交易实验的公开复盘：10 万美元模拟盘，终值 107,648 美元即收益 7.6% 对同期大盘 4.52%，峰值 120,431 美元，峰谷回撤 22.4%，最大单笔盈利 14,578 美元、最大单笔亏损 15,147 美元，作者自评回报“令人鼓舞但不可信赖”），https://medium.com/@jakenesler/i-gave-claude-code-100k-to-trade-with-in-the-last-month-and-beat-the-market-ece3fd6dcebc ，核实于 2026-08-31。
• Los Angeles Times, AI day traders seemed like the future. Then losses started（对 AI 日内交易现象的批评性报道，与上述复盘构成对照），https://www.latimes.com/business/story/2026-05-01/ai-day-traders-seemed-like-future-then-losses-started ，核实于 2026-08-31。
• 《Claude Code: The Definitive Guide to Agentic Development》（独立出版，2026）第 10 章（33 天实验完整弧线：首日七万五千美元即四分之三仓位、六分钟十六笔剥头皮、治理智能体退化为过度保守后被整体放弃、加密货币相关性与单日 13% 下跌、氛围交易变体）、第 11 章（一家大型 AI 公司十个团队的采纳记录：外围任务自动接受、工程师先审大约八成方案再打磨、核心逻辑详尽提示词加同步监督、管模型服务的团队研究时间砍八成、数据科学团队日常重构省两到四倍时间）。译文见 txt-ref-zh/claude-code-definitive/。
• 《Agentic Architectural Patterns for Building Multi-Agent Systems》（Arsanjani & Bustos，Packt 2026）第 7 章（金丝雀智能体测试／影子模式部署：影子路径把同一请求副本发新版本、结果只记录不生效，业务指标对比而非只看输出相似度，双路并行成本翻倍）。译文见 txt-ref-zh/agentic-architectural-patterns/。
• 《Building Reliable AI Systems》（Manning）第 10 章（影子测试：候选模型异步并行不影响用户体验、评测期模型成本翻倍须限在有代表性的时间窗、质量退化／更便宜模型质量相当／厂商弃用公告／能力缺口四个触发信号、模型选择是持续的运营决策），见 txt-ref-zh/building-reliable-ai-systems/（全书译文，数字保真核对通过）。
• 《Building AI Agent Platforms》（Ben O'Mahony、Fabian Nonnenmacher，O'Reilly Media 2027 Early Release）第 2 章（吵闹邻居问题：多团队共享平台服务时单个团队挤占资源拖累他人，速率限制、资源配额、优先级机制三缓解）。译文见 txt-ref-zh/building-agent-platforms/。
• Julian Soh《Building and Distributing Agentic AI》（Apress，2026）第 2 章（采纳率按逻辑斯谛增长建模而非线性、饱和段因流失与疲劳回落再回稳、发布日按初始采纳规模备容量、全员每分钟 token 的吞吐核算口径），见 txt-ref-zh/building-distributing-agentic-ai/。
• 《The Claude Code Operating Model》第 7 章（CI 哨兵的结构化裁决标签、别在评论文本里裸搜关键词；四阶段推进：只评论、黄牌不阻断、红牌阻断留人工覆盖、最后才主动修复，由驳回率决定升级），见 txt/claude-code-operating-model.txt（英文原文，第 7 章，行 7339-8676）。
• Dhivya Nagasubramanian《Agentic AI for Engineers》（Springer/Apress 2026）第 9 章（信任难建易毁，放权门槛按“会被记住的那次失败”设而非平均情形），见 txt/agentic-ai-for-engineers.txt（英文原文，第 9 章，行 11719-11723）。
• Micheal Lanham《AI Agents in Action》第二版（Manning，2026）第 8 章（智能体微服务容器化：一容器一智能体、容器化智能体经 API 或 MCP 服务器供前端智能体调用、Docker Compose 一份声明文件编排整条多智能体拓扑、镜像进生产前人工评估裁剪）。译文见 txt-ref-zh/ai-agents-in-action-2e/。
• shareAI-lab 开源教程仓库 learn-claude-code（MIT 许可，s11 站：慢工具后台执行、占位 tool_result 加任务编号、完成结果以独立通知进下一轮且不复用原调用 id；s12 站：cron 排程工具、到期入队空闲交付、至少一次交付语义、停机不补跑、定时回合与用户回合互斥并拒绝交互确认），https://github.com/shareAI-lab/learn-claude-code ，核实于 2026-09-15。
• 《Agentic Architectural Patterns for Building Multi-Agent Systems》（Arsanjani & Bustos，Packt 2026）第 12 章（架构跃迁的触发判据：单体先当最小可行智能体验证价值、日活用户量／专门化智能体增多／长跑异步需求三类信号、扩容从被动恐慌变规划事件），见 txt-ref-zh/agentic-architectural-patterns/。
• 《Claude Code: The Definitive Guide to Agentic Development》（独立出版，2026）第 1 章（派活讲目标与背景而非步骤、稻草人方案给模型一个可反应的具体起点、混合工具链：行内补全与智能体式多步操作混配）、第 8 章（“这可能是错的”限定语防模型照单全收）。见 txt-ref-zh/claude-code-definitive/。
• 《Claude Code: Up and Running》（Ken Kousen，O'Reilly 抢先版 2026）第 3 章（任务书要素：症状、期望行为、位置、本地惯例、边界；成功条件只讲结果不规定实现）。见 txt-ref-zh/claude-code-up-running/。
• 《Agentic Engineering》（Addy Osmani，O'Reilly Early Release 2026）第 5 章（收工对照验收：智能体完工后逐条报验收标准满足与否，缺口不留给生产环境发现），见 txt/agentic-engineering.txt（英文原文）。
• 《Building and Distributing Agentic AI Solutions》（Julian Soh 等，Apress 2026）第 7 章（交付位置：多租户 SaaS 对部署进客户订阅的托管应用、锁定资源组与数据驻留）、第 2 章（预配吞吐的承诺容量计费）、第 8 章（上架后治理动作：激活、部署、固定、阻止、移除、批准更新）。见 txt-ref-zh/building-distributing-agentic-ai/。
• 《Agentic AI for Healthcare》（Sairohith Thummarakoti 编，Routledge 2026）第 4 章（数据缺口主动收集：关键信息缺失时提示临床医生补齐或向患者发问卷，而非带缺口决策）。见 txt/agentic-ai-healthcare.txt（英文原文）。
• 《Building Agentic Applications with CrewAI and MCP》（Max Gfeller，Manning MEAP）4.1 节（多租户隔离：文件访问、数据库查询与持久状态按租户划开，日志、计费与用量分析随之分租户），见 txt/crewai-mcp.txt（英文原文，行 2400-2415）。
• 《Building Multimodal Generative AI and Agentic Applications》（Indrajit Kar，BPB 2026 中译）第 4 章（多租户 RAG：按租户拆库或命名空间分片、按租户身份做请求级路由）。见 txt-ref-zh/building-multimodal-agentic/。
• 《Agentic Mesh》（Eric Broda、Davis Broda，O'Reilly 2026）（用户可配置的状态转移通知：哪些状态跳变出提醒按用户默认与单次交互各自设定，注册表处理跳变并推送）。见 txt/agentic-mesh.txt（英文原文）。
• 《Agents and Multi-Agent Systems: Development Platforms, Toolkits, Technologies》（浏览器端客户端智能体：在浏览器里直接跑、把资源消耗从服务器挪到用户设备、一个链接即可分享，教学传播之用）。见 txt/agents-mas-platforms.txt（英文原文）。
• 《Designing AI Interfaces》（Louise Macfadyen，O'Reilly 2026）第 1 章（ELIZA 效应：人向生成人类式语言的系统投射理解与情感，1966 年 ELIZA 的来历与用户反应）。见 txt/designing-ai-interfaces.txt（英文原文）。
• 《Agentic AI For Dummies》（Pam Baker，Wiley 2026）第 13 章（Constitutional AI 训练法：模型按成文原则自我批评与修订的两阶段训练）。见 txt/agentic-ai-for-dummies.txt（英文原文）。
• 《Agentic AI For Dummies》（Pam Baker，Wiley 2026）第 7 章（人失掉有意义的介入能力，human-in-the-loop 就成了空话；协作的前提是人保得住策略理解，不是对模型的每步提议照单全签）与第 10 章（监督流程把监督者拖疲拖垮，人就一路闭眼放行；有信息量、要紧而及时的监督标记，才换得来人认真看）。见 txt/agentic-ai-for-dummies.txt（英文原文）。
• 《Agentic GraphRAG》（Anthony Alcaraz，O'Reilly 2026 中译）第 7 章（自我修改的安全包络：候选改进先过分级验证、出现回归即自动回滚，每次自我修改连同触发它的诊断与因果谱系记入版本化学习日志），译文见 txt-ref-zh/agentic-graphrag/。
• 《AI Agent Handbook》（开源白皮书，Apache 2.0 许可）第 16 章（上线前的模拟验证：模拟用户承载会记错、会变卦的对手方，模拟环境承载工具与业务状态，工具按剧本超时与失败、状态可保存重放、执行无真实后果，按业务终态判分，运行留档成可回看的证据）。见 参考资料/ai-agent-handbook/，核实于 2026-10-01。