组合：把零件集成成一个真实系统

09.1选型卡：在双轴上定位，而非背模式清单

模式选型的本质是把任务投影到两根轴上——可预测性↔灵活性、自主度等级——而不是记忆一张模式清单。

Anthropic 在《Building Effective Agents》里给了一个根本二分：workflow 是用代码预先编排 LLM 与工具的固定路径，agent 是让 LLM 自己在循环里动态决定步骤与工具调用。判据是可预测性——定义良好、要一致性的任务用 workflow，要灵活、要模型自主决策的用 agent。这一层之下的机制是成本：越往 agent 端走，每个决策点都多一次 LLM 调用，延迟与成本随决策点数量线性上升；更糟的是错误会在循环里复合（compounding errors），一步偏差喂给下一步，越长的循环越放大。这正是"能 workflow 别 agent"的物理原因——agentic 系统是用延迟和成本换开放任务的表现，对已定义良好的任务，这笔交换是纯亏。

09.2六步选型法：一棵默认偏简侧的决策树

六步选型法把双轴展开成一串短路式判断，每一步用"最简方案能否满足"做剪枝，默认答案都偏向更简单的那一侧。

这棵树的机制是短路剪枝：从最便宜的方案开始，逐步问"它还不够吗"，不够才进下一层。Step 1 决定该不该上 agent——OpenAI 给三条判据：(1) 需要细腻判断、处理例外、上下文敏感的复杂决策（如退款审批）；(2) 规则集臃肿、改起来易错的难维护规则（如供应商安全审查）；(3) 重度依赖自然语言、文档解读、对话的非结构化数据（如保险理赔）。三条都不满足时，"a deterministic solution may suffice"——确定性方案就够，止步，别上 agent。Step 2 任务能否拆成固定顺序子步骤——能则 prompt chaining，仍是 workflow。Step 3 步骤数是否运行时才知道——是则需要动态编排（orchestrator-workers 或 agent loop）。Step 4 是否需要跨会话记忆——单轮够则无状态，跨上下文窗口的长程任务才上 harness 的状态工件。Step 5 是否需要多 agent——默认否。Step 6 按已识别风险叠护栏、按失败阈值设人在回路。

Step 5 的拆分信号（最反直觉的一步）：默认单 agent，靠加工具把单 agent 顶满。真正的拆分触发信号是两个可观测的失效——prompt 里 if-then-else 分支爆炸，或模型反复选错工具——而不是"看起来该分开"的职责直觉。关于工具选错，OpenAI 给了一个反直觉判据：问题不在工具数量而在相似/重叠度——有的实现稳管 >15 个界限清晰的工具，有的 <10 个重叠工具就失效。所以先靠改名、明确参数、写详细描述提升工具清晰度，无效再拆 agent。要拆时分两种形态：Manager 模式（agents-as-tools，中心 agent 用 tool call 委派并综合结果）与 Decentralized 模式（peers 之间 handoff 单向转移执行权）。这两种可统一建模为图——这正复用了第 01 章执行拓扑那根轴：manager 的边是 tool call（可回中心综合），decentralized 的边是 handoff（单向、不回头）。

09.3集成 Harness：装配托住模型的运行时

Harness 是把工具、运行循环、记忆、护栏、可观测五件事集成在一起、托住模型自主性的"外壳"。

先看运行内核。agent 的 run 循环就是一个 while：LLM → 调用工具 → 读环境反馈 → 再决策，直到退出条件。OpenAI 列的常见退出条件有四个：final-output 工具被调用、模型返回无工具调用的回复、报错、或达到最大轮数（max turns）。这就是"agents are just LLMs using tools in a loop"的字面实现——它正是第 01 章那个原子循环加上一个 until。护栏这一面用纵深防御：单个护栏覆盖不全，多个专用护栏叠成多层——相关性分类器（挡跑题）、安全分类器（挡越狱/提示注入）、PII 过滤、moderation（有害内容）、工具风险分级（按只读/可逆/权限/财务影响打 low/med/high，高风险暂停或升级人工）、规则型（黑名单/长度/正则挡 SQLi）、输出校验。SDK 默认乐观执行：主 agent 先出 output，护栏并发跑，违规抛 tripwire——这平衡了安全与延迟，串行前置会徒增延迟。人在回路则有两类触发：超过失败阈值（多次无法理解意图就升级人工），以及高风险/不可逆动作（取消订单、大额退款、付款）在信心建立前都要人工监督。

横向集成纪律（LangChain 的啤酒比喻）：harness 里哪些该自建、哪些该外包？Harrison Chase 的划分是——智能体基础设施（状态持久化、任务队列、后台运行、部署伸缩容错）"不会让你的啤酒更好喝"，该外包；认知架构（应用专属的控制流、状态追踪、工具选择与 prompt 策略）"会让啤酒更好喝"，必须自有。可靠性来自任务专属架构，通用认知架构（如把一切塞进 messages-in-a-thread）会被框架的预设形态卡死、限制复杂高价值 agent 能造的形态。所以任务特异性应落在工具与 prompt 上，harness 骨架保持相对固定。

# 选型 → harness 集成的一体化决策（浓缩 L39 + L40 + L41）
def pick_and_build(task):
    # L40 Step1：该不该上 agent（OpenAI 三判据）
    if not (task.complex_judgment or task.brittle_rules or task.unstructured):
        return Deterministic()                       # 确定性方案就够，止步

    # L39/L40 Step2-3：双轴定位 → 选 workflow 模式（能 workflow 别 agent）
    if task.steps_fixed_at_design_time:
        if task.needs_classify_then_route: return Routing()
        if task.subtasks_independent:      return Parallelization(mode="section|vote")
        return PromptChaining()
    if task.subtasks_unknown_until_runtime and task.has_clear_eval_criteria:
        return EvaluatorOptimizer()
    if task.subtasks_unknown_until_runtime:
        return OrchestratorWorkers()                 # 仍是 workflow，动态拆子任务

    # 走到这里才需要真正的 agent 循环
    agent = SingleAgent(model=best_model, tools=[], instructions=routine)

    # L40 Step5：单 agent 顶满，仅在失效信号下才拆多 agent
    while agent.fails_complex_instructions or agent.picks_wrong_tool:
        if not improve_tool_clarity(agent):          # 先改名 / 参数 / 描述
            agent = ManagerPattern() if task.needs_central_synthesis \
                    else DecentralizedHandoffs()
            break

    # L41：集成 harness = 工具 + 循环 + 记忆 + 护栏 + 观测
    harness = Harness(
        loop=run_until(exit=["final_output", "no_tool_call", "error", "max_turns"]),
        memory=DiskState("claude-progress.txt", "feature-list.json", "git"),
        guardrails=[relevance, safety, pii, moderation, tool_risk_rating, output_check],
        observability=[commit_per_feature, e2e_self_verify],
        human_in_loop=on(failure_threshold, high_risk_action),
    )
    return harness.wrap(agent)
# 纪律：每一步默认选更简的一侧；只有 eval 证明改善才升级复杂度

09.4长程 Harness：状态外化到磁盘工件

长程 agent 的可靠性主要不靠更大的上下文窗口，而靠把状态外化成磁盘工件——记忆是文件系统，不是 context。

Anthropic 在《Effective Harnesses for Long-Running Agents》里给的机制是双 agent + 磁盘工件。Initializer agent 只跑一次：搭好环境、把 prompt 展开成 >200 条 feature-list.json、写好 init.sh。Coding agent 每个 session 被反复唤醒，按固定开机流程推进——读 git log 与 claude-progress.txt → 挑最高优先级未完成 feature → 跑 init.sh → 先做端到端自验 → 做一个 feature 的增量 → 跑测试 → 写进度笔记 → git commit。状态靠这些磁盘工件而非上下文压缩来桥接：记忆 = 进度笔记 + feature 清单 + git 历史（可回滚的检查点），观测 = 每步 commit message + E2E 验证结果。这呼应了第 03 章的结论——长任务真正的 source of truth 不是 context window，而是写在外部的进度文件。