选择 Agentic Architectures：决策驱动速成课

一门关于 pattern selection 的概念速成课：什么时候用 sequential workflow，什么时候用 single agent + ReAct + tools，什么时候用 planning + ReAct execution，什么时候用 multi-agent specialist system（四种核心模式），以及什么时候在任一核心模式上叠加 reflection。目标读者是已经交付过 agents、需要按原则选择 architecture，而不是按看起来是否高级来选择的 engineers。

*22 个概念 • 5 个决策 • 4 条学习路径。Reader track：2–3 小时纯概念阅读。Beginner / Intermediate / Advanced tracks：约 1 天、2–3 天、4–5 天。诚实估计：Reader track 2–3 小时；团队真正内化 pattern selection 作为工作纪律，需要 4–5 天。进入 Part 5 的 decision lab 前，请先选择 track。*

Anchor article：Bala Priya C, "Choosing the Right Agentic Design Pattern: A Decision-Tree Approach," Machine Learning Mastery, May 15, 2026：machinelearningmastery.com/choosing-the-right-agentic-design-pattern-a-decision-tree-approach。本课的 decision tree 以她的文章为脊柱；本课增加的是 composition layer：每种 pattern 对 deployment topology 和 eval suite 意味着什么。

---

白话版（先读这里）

你已经能构建 agents。也许是 Digital FTE 课程里 Maya 构建的 customer-support Worker，也许是 eval-driven course里的 evaluation agent，也许是你在 cloud deployment course中一路推到 production 的 Tier-1 Support agent。现在你能构建一个 agent 了。 但你还不一定能有原则地决定：下一次到底应该构建 哪一种 agent。

production AI 中有一个真实失败模式：engineers 会伸手拿看起来最高级的 pattern，通常是 multi-agent，即使任务本来只需要 sequential workflow，甚至五个步骤里有三个根本不需要 LLM。为了一个单 agent + 两个 tools 一天能处理的问题，花几周做 orchestration。相反的失败模式同样真实： 任务确实需要拆成 specialists 时，engineers 却硬塞进一个 long system prompt 的 single agent，最后 agent 被不适合一个 mental model 的 context 压垮。

Pattern selection 是 build 前的 design work。 它问的是：「这个 agent system 到底应该是什么形状？」答案是有原则的：问任务五个问题，答案映射到五种 starting patterns。本课教这五个问题、五种 patterns、说明 pattern 选错的 failure signals，以及交付真实系统时最重要的部分：每种 pattern 对 deployment topology 和 eval suite 的含义。

纪律不是「永远选最简单 pattern」。纪律是「选择与任务真实要求匹配的最简单 pattern；只有在能命名具体任务属性要求复杂度时，才增加复杂度」。multi-agent system 只有在 specialization 或 scale 造成真实瓶颈时才是正确答案，不是因为它在 slide 上更高级。

如果你还没学过 Agent Factory 之前的课程

本课会引用 operational envelope (Inngest)、eval discipline 和 cloud deployment，并把前面课程里的 Maya Tier-1 Support agent 作为 running example。即使没读过这些，也完全可以使用本课。 五问 decision tree、五种 patterns 和 failure-signal 纪律本身就是可迁移框架。

没有前置课程时，第一遍按这个顺序读：

• Part 1：pattern-selection problem
• Part 2：five-question decision tree
• Part 3：five patterns，第一遍略读 operational-envelope sidebars
• Part 4：failure signals and revision
• Part 5：decision lab
• Part 7：closing

把 cross-references 当成一般原则的具体例子，而不是准入门槛。框架本身不依赖它们。

Platform translation table：Agent Factory 选择对应到什么

如果你使用不同 stack，这张表把 Agent Factory 引用映射到 2026 年常见替代品。decision tree、five patterns、failure signals 和 anti-pattern gallery 在这些平台上完全一样；只有 primitive names 改变。

Agent Factory reference	2026 常见替代	这一层做什么
Inngest（operational envelope）	Temporal、Restate、Dapr Workflows、AWS Step Functions、Azure Durable Functions、LangGraph	triggers、durable execution、flow control、HITL gates
OpenAI Agents SDK（agent engine）	LangGraph、AutoGen、CrewAI、AWS Strands、Pydantic AI、LlamaIndex Workflows	agent loop、tool routing、multi-agent composition、structured output
Phoenix / Arize（trace observability）	Langfuse、Helicone、LangSmith、Logfire、Honeycomb、Datadog APM	per-trace agent behavior observability 和 trace-to-eval pipeline
Azure Container Apps（harness runtime）	AWS Fargate、Google Cloud Run、Fly.io、Railway、Render、Kubernetes	long-running HTTP service host、autoscale、secrets、ingress
Neon Postgres（durable state）	Supabase、AWS RDS Postgres、PlanetScale、CockroachDB、Google Cloud SQL	sessions、runs、traces、audit log
Cloudflare R2（file storage）	AWS S3、Google Cloud Storage、Azure Blob、Backblaze B2	inputs、outputs、knowledge artifacts
Cloudflare Sandbox（code execution）	E2B、Modal、Daytona、Vercel Sandbox、Fly.io Machines、Cloudflare Containers	agent-generated code 的隔离 workspace
ctx.step.run(name, fn)	Temporal activity、Step Functions Task、LangGraph node	retry 时 memoize 的 durable checkpoint
ctx.step.wait_for_event(...)	Temporal wait condition、Step Functions task token、LangGraph interrupt	等待 event 或 timeout 的 HITL primitive
Agent(...) + Runner.run()	LangGraph Agent.execute()、AutoGen agent call、CrewAI kickoff()	运行 agent loop
@function_tool	LangChain @tool、AutoGen Tool(...)、Pydantic models	把函数暴露为 agent tool
handoff(target_agent)	LangGraph Command(goto=...)、AutoGen nested chats、CrewAI delegation	specialist 接管 conversation
Agent.as_tool()	subgraph-as-node、nested agent call、CrewAI as_tool patterns	coordinator 把 specialist 当作 tool 调用
output_guardrail	custom node + conditional edge、validator pattern、guardrails	agent output 的 critique / validation pass

当本课说「wrap Runner.run() in step.run」，如果你使用 Temporal + LangGraph，就读作「把 Agent.execute() 放进 workflow.execute_activity()」。architecture argument 相同，语法不同。

Agent.as_tool() 与 handoff() 的区别不总能一一映射。OpenAI Agents SDK 把「coordinator 保持控制」和「specialist 接管」做成一等 primitives。很多 framework 会合并或只实现其中一半。重要的是这个架构区别，不是 primitive 名称。

---

Glossary（读一次，需要时回来查）

展开完整术语表。

• Agentic design pattern。 AI agent systems 的常见 architecture shape：sequential workflow、ReAct + tools、planning + execution、reflection、multi-agent specialist。
• Sequential workflow。 固定步骤 pipeline，每步输出进入下一步。solution path 事先已知；LLM calls 只用于 interpretation 或 generation，不用于决定下一步。
• ReAct (Reason + Act)。 agent 在 reasoning 和 action（通常是 tool call）之间交替，观察结果后继续。关键属性：下一步 action 在 runtime 决定。
• Planning agent。 execution 前先产生显式 plan 的 agent。plan 组织工作；单个 step 内部仍可使用 ReAct。
• Reflection。 agent 生成输出后，按明确标准 critique，再根据 critique refine。增加 latency 和 cost；只有 criteria 可检查且错误昂贵时才有价值。
• Multi-agent specialist system。 多个 distinct-role agents（researcher、writer、reviewer）协作，由 routing 或 supervisor agent 协调。
• Solution path。 解决任务的步骤序列。known path 代表 runtime 前可定义；unknown path 代表步骤从调查反馈中浮现。
• Task structure。 主要阶段及依赖。articulable structure 代表 execution 前可描述；emergent structure 代表 execution 中才显现。
• Architectural fit。 pattern assumptions 与 task actual properties 的匹配。pattern selection 是 fit-matching，不是 capability-matching。
• Coordination overhead。 多 agents 或 handoffs 带来的 token、latency、debugging complexity 和 failure modes 成本。
• Failure signal。 runtime symptom，说明当前 pattern 与任务不匹配。
• Pattern composition。 在大型系统不同层使用不同 patterns。
• Agent。 OpenAI Agents SDK 的核心类：由 instructions=、可选 tools=、可选 output_type=、可选 handoffs= 定义。
• Runner.run(agent, input)。 SDK 调用，运行 Agent 直到产出 final output。SDK 内部运行 reason-act-observe loop。
• Operational envelope。 唤醒 agent function、在 crash 中存活、限制 load、协调 HITL 的 runtime layer。

---

Are you ready?（prerequisites）

1. 你已经构建过第一个 agent，或有等价经验。 你应该理解 agent loop、tool call 和 structured output。
2. 你至少维护过一个能工作的 agent。 你需要经历过 architecture choice 的后果。
3. 你能读 pseudocode。 本课概念为主，可执行代码很少。
4. 可选但强烈建议：完成 eval 和 cloud deployment 课程。 本课最重要的贡献，是把 pattern selection 与 deployment topology、eval suite 组合起来。

缺第 4 条也可以继续读；把 deployment-composition 和 eval-composition sidebars 当成 preview。

先知道这些粗糙边界（honest scope）

• 这是 conceptual course，不是 code course。 它教你 选择 architecture，不教你 实现 architecture。
• 五种 patterns 不穷尽现实。 现实里还有 graph-based systems、debate patterns、blackboard patterns、hierarchical task networks 等。本课覆盖的是 dominant starting points。
• decision tree 是起点，不是最终答案。 真实 architectures 会演化。single agent 可能长成 multi-agent；planning system 也可能简化为 sequential workflow。
• cost 和 latency 是 architecture choice 的一部分。 reflection 增加 latency，multi-agent 增加 tokens，planning 增加额外 LLM call。
• article 是脊柱；composition layer 是扩展。 如果只读过文章，本课增加的是 production discipline。

四条学习路径

Track	Time	你完成什么	适合谁
Reader	约 2–3 小时	Part 1、Part 2、Part 3、Part 4 和 closing	engineering leaders、platform architects、curious non-engineers
Beginner	约 1 天	Reader + lab decisions 1–2	新接触 agentic architecture 的 engineers
Intermediate	约 2–3 天	Beginner + decisions 3–4，加入 deployment topology 和 eval signals	正在 shipping agentic systems 的 engineers
Advanced	约 4–5 天	Intermediate + decision 5 + Parts 6 & 7	senior engineers 和 tech leads

Minimum viable path： 读 Part 1、Part 2 和 lab 的 Decision 1（Maya Tier-1 Support）。约 90 分钟后，你就能用五个问题分类一个新任务并选择 starting pattern。

结束时你会得到什么

Reader track 得到理解：能解释为什么 pattern selection 要在 code 前发生；能描述五种 patterns 及其 task assumptions；能识别五个 common failure signals。

Beginner / Intermediate / Advanced tracks 会形成工作纪律：

• 能对新 task 走五问 decision tree，选择 principled starting pattern。
• 能为每种 pattern 在你的 cloud stack 上 sketch deployment topology。
• 能把每种 pattern 的 likely failure modes 映射到具体 eval signals。
• 能产出团队可共享的一页「classify-this-task」design-review template。

---

TL;DR：本课 defend 的四个 claims

1. Pattern selection 是 architectural fit，不是 capability matching。 每个 pattern 对 task 有假设。正确 pattern 是 assumptions 匹配 task properties 的那个，不是能力最多、结构最炫的那个。

   四种 core patterns + 一个 additive layer。 Q1–Q3 选择 core pattern：sequential workflow、single agent + ReAct + tools、planning + ReAct execution、或 multi-agent specialist system。Q4 决定是否在 core 上增加 reflection。Reflection 不是第五个平级 pattern，而是 quality-control layer。

2. 关于 task 的五个问题决定 architecture。 Q1–Q3 选 core pattern；Q4 决定 reflection；Q5 决定是否升级到 multi-agent。答案会 deterministically 映射到 starting architecture。

3. Pattern selection 与 deployment topology、eval signals 组合。 sequential workflow 不需要 sandbox execution；multi-agent systems 需要更严格 audit logging，因为 coordination failures 最难 debug。

4. Pattern 选错会在 production 中暴露为 failure signals。 discipline 不是一次性选择，而是选择、观察信号、修正的循环。

你要学习的形状（一张图，后面反复回来）

---

Part 1：Pattern-selection problem

Concept 1：Pattern selection 是 build 前的 design work

agent architecture 的第一个问题不是「用哪个 framework」，而是「任务本身是什么形状」。如果 solution path 固定，用 adaptive agent loop 只会增加成本。如果 solution path 未知，用 sequential workflow 会让系统在第一次异常输入上崩掉。pattern selection 把 architecture discussion 提前到 coding 前。

Concept 2：每种 pattern 都对 task 做了不同假设

sequential workflow 假设 path known、steps stable。single agent + ReAct 假设 path unknown，但一个 mental model 足以处理。planning + ReAct 假设 structure 可在 execution 前描述，但每个 step 仍需 adaptive execution。reflection 假设质量 criteria 可检查且错误昂贵。multi-agent 假设 specialization、context 或 scale 已经造成瓶颈。

Concept 3：两种失败模式：overshooting 和 undershooting

overshooting 是 pattern 比任务需要的更复杂：为 invoice processing 上 ReAct，为 simple generation 上 multi-agent，为 vague quality task 上 reflection。undershooting 是 pattern 比任务需要的更简单：让一个 giant agent 处理多个 domains，或对必须验证的输出跳过 reflection。overshoot 更常见，因为 demos 喜欢 elaborate patterns；undershoot 在 production 中更危险，因为系统会「看起来能用」，直到边界条件出现。

---

Part 2：五问 decision tree

五个问题按顺序问。不要先选 pattern 再找理由；先回答 task property，再让答案指向 pattern。

Concept 4：Q1：solution path 能否提前定义？

如果能，先去 Q2。若不能，说明任务需要 adaptive reasoning，跳到 Q3。已知 path 的例子：invoice intake → extract → validate → store → notify。未知 path 的例子：debug 一个 intermittent production incident。

Concept 5：Q2：workflow 是否跨 runs 固定稳定？

若 path 已知且 workflow 固定，选择 sequential workflow。这种任务不需要 agent 每轮决定下一步。你可以把少量 LLM calls 放进固定 pipeline 的特定步骤。若 workflow 并不稳定，说明你之前把 path known 判断得太乐观，需要回到 adaptive patterns。

Concept 6：Q3：task structure 是否能在 execution 前表达？

如果 solution path unknown，但你能在开始前描述主要 stages 和 dependencies，选择 planning + ReAct execution。例如 market research：先 define questions，再 collect data，再 synthesize，再 write report。若 structure 也无法提前表达，选择 single agent + ReAct + tools，让 agent 在 runtime 中 reason-act-observe。

Concept 7：Q4：quality 是否比 speed 更重要，且 criteria 可检查？

如果是，在 core pattern 上添加 reflection layer。reflection 只有在 criteria 明确时才有价值：SQL correctness、policy compliance、citation validity、safety constraints。若 criteria 只是「更好」「更聪明」「更有战略感」，reflection 只会制造自我赞同的昂贵回音。

Concept 8：Q5：是否存在 specialization、context 或 scale bottleneck？

如果一个 agent 的 mental model 太大、context 太宽，或任务天然可并行到不同 specialists，升级为 multi-agent specialist system。不要因为看起来高级而升级；要能命名瓶颈：domain specialization、context isolation、parallel scale，或需要 explicit handoff ownership。

Concept 8.5：OpenAI Agents SDK primitives：每种 pattern 用什么

Pattern	SDK primitives
Sequential workflow	multiple Agent(...) 或 structured-output calls，由外部 code 固定顺序调用
Single agent + ReAct + tools	一个 Agent(...)，带 tools=[...]，通过 Runner.run() 执行
Planning + ReAct execution	planner Agent 产出 structured plan；每个 step 调用 executor agents
Reflection layer	output_guardrail 或 critic agent + retry/escalate path
Multi-agent specialist	handoff(...) 或 Agent.as_tool()，加 coordinator / supervisor

这张表的重点不是 SDK 名称，而是 control ownership。sequential workflow 的控制权在普通 application code；agent 只负责一个窄步骤。single ReAct agent 的控制权在 agent loop；下一步由 runtime observation 决定。planning pattern 把控制权拆成两层：planner 决定 stage，executor 在 stage 内 adaptive。reflection layer 不改变 core control flow，只在 output boundary 增加 critique/validation。multi-agent 则把 control ownership 变成架构问题：coordinator 是否保持控制，还是 specialist 接管 conversation？

一个设计 review 中可以直接问：

For this pattern, who owns the next-step decision?

- Application code?
- A single agent loop?
- A planner-generated plan?
- A coordinator agent?
- A specialist agent after handoff?

If we cannot answer this clearly, the architecture is not yet designed.

Concept 8.6：每种 pattern 的 operational envelope considerations

越 elaborate 的 pattern，越需要 operational envelope。sequential workflow 需要最少：durable steps 和 retries。single agent + ReAct 需要 step budget、tool-call tracing 和 timeout controls。planning + ReAct 需要 plan table、per-step state 和 background workers。reflection 需要记录 generator output、critique、retry decision。multi-agent 需要 per-specialist traces、handoff audit、fan-out/fan-in control 和 coordination failure visibility。

---

Part 3：五种 patterns 深入

Concept 9：Sequential workflow：shape、deployment、eval signals

Sequential workflow 是固定 pipeline。每个 step 的输出进入下一步；LLM 只是某些 step 的 implementation detail。典型场景：invoice intake、document classification、compliance checklist、structured extraction。

# Two narrow agents: each does ONE LLM-step in the workflow.
# Notice: no tools, no agentic loop. Just structured-output extraction.
invoice = extract_invoice_agent.run(pdf_text)
validated = validate_invoice(invoice, policy)
store_invoice(validated)
notify_accounting(validated)

deployment 最小，eval 也最直接：每一步有 expected input/output。failure signal 是 agentic overhead 过重、latency 不必要、LLM 在不该 decision 的地方 decision。

更生产化的 sequential workflow 通常长这样：普通 code 固定顺序，LLM 只在 extraction 或 classification step 中出现，所有 deterministic checks 都用代码完成。

async def process_invoice(pdf_bytes: bytes) -> StoredInvoice:
    text = await ocr_pdf(pdf_bytes)
    extracted = await Runner.run(extract_invoice_agent, text)
    validated = validate_against_policy(extracted.final_output)
    duplicate = await find_duplicate_invoice(validated.invoice_number)

    if duplicate:
        raise DuplicateInvoiceError(validated.invoice_number)

    stored = await store_invoice(validated)
    await notify_accounting(stored.id)
    return stored

eval suite 也应跟着简单：field-level accuracy、schema validity、duplicate detection、policy rule pass/fail、end-to-end latency。不要给 sequential workflow 写 multi-agent style eval；那会让测试关注错 failure mode。

Concept 10：Single agent + ReAct + tools：shape、deployment、eval signals

single ReAct agent 适合 path unknown 但一个 mental model 足够的任务。agent 根据当前 observation 决定下一步 tool call。典型场景：support triage、investigation、light debugging、account lookup。

@function_tool
async def search_orders(customer_id: str) -> list[Order]:
    ...

support_agent = Agent(
    name="Tier-1 Support",
    instructions="Resolve customer issues using the available tools.",
    tools=[search_orders, refund_order, lookup_policy],
)
result = Runner.run(support_agent, user_message)

eval signals：tool-call correctness、step count、unnecessary loops、policy violations、escalation quality。deployment 需要 trace observability 和 tool permission boundaries。

single ReAct 的生产风险集中在 tool boundary：tool schema 是否窄、tool 是否幂等、agent 是否能越权、loop 是否有 budget。一个 support agent 的 minimum envelope 应该包含：

result = await Runner.run(
    support_agent,
    user_message,
    max_turns=8,
    context={
        "customer_id": customer_id,
        "allowed_actions": ["lookup_order", "lookup_policy", "draft_reply"],
        "refund_cap_cents": 5_000,
    },
)

如果 max_turns 经常被打满，或者 agent 反复调用同一个 tool 但没有新信息，说明 pattern 可能需要 planning、stronger tool design，或更窄的 task framing。

Concept 11：Planning + ReAct execution：shape、deployment、eval signals

planning pattern 适合 task structure 可提前表达，但每一步仍需 adaptive execution 的任务。planner 先产出 stages 和 dependencies；executors 再执行每个 step。

plan = Runner.run(planner_agent, "Research this market and produce a report")
for step in plan.steps:
    result = Runner.run(executor_for(step), step.input)
    save_step_result(step.id, result)

eval signals：plan completeness、step ordering、plan/execution divergence、stale plan not updated、unnecessary plan complexity。deployment 需要 per-step durable state 和 retry boundaries。

planning pattern 必须把 plan 当作 first-class artifact，而不是聊天中的一段文字。一个最小 plan schema 可以这样：

class PlanStep(BaseModel):
    id: str
    goal: str
    required_inputs: list[str]
    expected_output: str
    verifier: str


class ResearchPlan(BaseModel):
    task: str
    steps: list[PlanStep]
    assumptions: list[str]
    stop_conditions: list[str]

生产中要记录三类 divergence：step skipped、step added、step repeated。不是所有 divergence 都是错，但它们都应可见。若每个 run 都大量偏离初始 plan，说明 task structure 比你以为的更 emergent；纯 ReAct 或 periodic replanning 可能更合适。

Concept 12：Single agent + reflection：shape、deployment、eval signals

reflection 是 additive layer，不是独立 core。它适合输出质量重要、criteria 可检查、错误昂贵的场景。critic agent 或 guardrail 对 generator output 做 critique；系统可 retry、escalate 或 fail loudly。

@output_guardrail
async def sql_correctness_guardrail(ctx, agent, output):
    critique = await Runner.run(sql_critic_agent, output)
    return GuardrailFunctionOutput(
        output_info=critique,
        tripwire_triggered=not critique.is_safe,
    )

eval signals：critique 是否抓到真实错误、false positives、retry 是否改善输出、latency 是否值得。若 criteria vague，reflection 会退化成贵而无用的自我确认。

reflection 的好 criteria 是可检查的：

Good criteria	Bad criteria
SQL 只读，不含 DROP、DELETE、UPDATE	SQL 是否“看起来合理”
每个 claim 至少 1 个 citation	report 是否“更有洞察”
refund 不超过 policy cap	customer reply 是否“语气更好”
JSON 满足 schema	answer 是否“更聪明”

设计 reflection 时，先写 tripwire，再写 prose critique。tripwire 决定系统是否 retry/escalate；prose critique 只是帮助下一轮改进。

Concept 13：Multi-agent specialist system：shape、deployment、eval signals

multi-agent 适合 specialization、context 或 scale 瓶颈真实存在时。specialists 各自有 tools、instructions 和 context；coordinator 决定调用谁、何时合并结果。

researcher = Agent(name="Researcher", tools=[web_search])
writer = Agent(name="Writer")
reviewer = Agent(name="Reviewer")

coordinator = Agent(
    name="Coordinator",
    tools=[
        researcher.as_tool(),
        writer.as_tool(),
        reviewer.as_tool(),
    ],
)

as_tool() 表示 coordinator 仍控制流程；handoff() 表示 specialist 接管 conversation。eval signals：handoff correctness、specialist disagreement、coordination loops、missing synthesis、parallel run consistency。deployment 需要最强 audit logging，因为 coordination failures 最难复现。

multi-agent 有两种常见 composition：

# Coordinator remains in charge.
coordinator = Agent(
    name="Coordinator",
    tools=[researcher.as_tool(), writer.as_tool(), reviewer.as_tool()],
)

# Specialist takes over the conversation.
triage_agent = Agent(
    name="Triage",
    handoffs=[billing_agent, technical_support_agent, legal_agent],
)

第一种适合 coordinator 汇总 specialists 的结果；第二种适合 specialist 需要直接与用户互动。选错会产生明显 failure：as_tool() 用在需要 long interaction 的 specialist 上，会让 coordinator 成为 bottleneck；handoff() 用在只需一次 specialist judgment 的场景，会让 control flow 难追踪。

---

Part 4：Failure signals and pattern revision

Concept 14：五个 failure signals（以及各自含义）

Signal	说明	可能修正
Agent 反复回到已解决工作	structure 不足，ReAct 在原地打转	加 planning 或 fixed workflow
Planner 计划和 execution 持续分离	任务比 planner 假设更 emergent	降级到 ReAct 或重新规划机制
Reflection 没改善输出	criteria 不可检查或 critic 太弱	移除 reflection，换 human review 或强化 criteria
One giant agent context 爆炸	specialization/context bottleneck 存在	拆成 multi-agent specialists
Multi-agent coordination 成为主要 bug 来源	pattern overshot	回到 single agent 或 fixed workflow

Concept 15：不放弃 architecture 的 targeted fixes

pattern wrong 与 implementation weak 不同。先做 targeted fixes：收紧 tools、加 step budget、显式 write plan、缩短 context、增加 eval signal、把 reflection criteria 改成可检查。只有 fixes 不解决 failure signal 时，才重选 pattern。

Concept 16：decision tree 何时会错

decision tree 是 starting heuristic，不是 oracle。它会在 task properties 误判、用户未披露约束、production data 改变任务形状时出错。正确 response 是观察 failure signals 并 revise architecture，而不是 defend 初选。

Concept 16.5：Anti-pattern gallery：常见错误选择以及替代方案

---

Part 5：Decision lab

下面五个 decisions 是把 framework 内化的地方。每个都按同一模板回答：Q1 solution path？Q2 fixed workflow？Q3 articulable structure？Q4 reflection？Q5 multi-agent bottleneck？最后给出 starting pattern、deployment implication、eval signals 和 failure signal to watch。

Decision 1：Maya 的 Tier-1 Support agent

任务：处理客户支持请求，查订单、查 policy、决定 refund 或 escalate。solution path 不是固定；同一个 mental model 足够；需要 tools；quality 重要但可先用 evals 和 policies 控制；没有 specialization bottleneck。Starting pattern：single agent + ReAct + tools。 eval signals：tool-call correctness、refund policy compliance、escalation quality、turn count。

Decision 2：Incident response agent

任务：生产事故响应。path unknown，但 stages 可描述：triage、collect signals、hypothesis、mitigation、postmortem。每一步需要 tools。Starting pattern：planning + ReAct execution。 eval signals：plan quality、step ordering、mitigation safety、whether execution diverges from plan。

Decision 3：Market research agent

任务：研究市场并形成 report。structure 可描述，但 research 子任务可并行；quality 和 citations 可检查；context 容量容易成为瓶颈。Starting pattern：planning + ReAct execution，加 reflection；规模变大时升级 multi-agent specialists。 eval signals：source quality、claim support、coverage、synthesis quality。

Decision 4：Enterprise onboarding agent

任务：引导大型客户 onboarding，涉及 legal、security、finance、technical setup、change management。domain specialization 明确，context 宽，handoffs 重要。Starting pattern：multi-agent specialist system。 eval signals：handoff correctness、specialist coverage、audit trail、customer-facing consistency。

Decision 5：Coding agent（advanced track）

任务：在真实 codebase 中实现 issues。solution path 对每个 issue 部分可定义，但 execution 需要 adaptive tool use；quality criteria 可检查（tests、types、lint）；context 难题真实存在。Starting pattern：single agent + ReAct + tools，包在 TDD 和 vertical-slice workflow 中；需要 large-scale orchestration 时用 multi-agent 或 AFK workers。 eval signals：test pass、diff size、interface changes、review findings、regression rate。

---

Part 6：Honest frontiers

Concept 17：Cost 和 latency 是 architecture constraints，不是 afterthoughts

每个 pattern 都有成本。sequential workflow 是 baseline。single ReAct agent 可能是 3–10x，因为多轮 tool calls。planning + ReAct 增加 planner call 和 per-step execution，可能 5–15x。reflection 在 core pattern 上再加 2–3x。multi-agent specialist system 可能最大，因为每个 specialist 都有 context、model calls、traces 和 coordination overhead。选择 pattern 时，成本和 latency 必须作为 constraints 写进 design review。

Concept 18：Pattern composition：不同 layers 使用多个 patterns

真实系统经常组合 patterns：顶层 planner 拆任务；每个 step 内部是 ReAct agent；最终 synthesis 上加 reflection；某些 domain 交给 specialists。composition 不是问题，问题是每层要有清楚理由。不要把 composition 当装饰；每加一层，都要写明它解决哪个 task property。

---

Part 7：Closing

Concept 19：Pattern selection 是 Agent Factory curriculum 的 connective tissue

前面的课程教你 build agents、把它们变成 Digital FTE、包上 nervous system、加 evals、部署到 cloud。本课回答这些能力之间的选择问题：面对一个新任务，应该先构建什么形状？这个选择连接了 implementation、operations 和 evaluation。

pattern selection 的成熟标志，不是你会说出五种 pattern 名称，而是你能在 design review 中 defend 一句话：

「我们选这个 pattern，是因为任务具有这些 properties；如果这些 runtime signals 出现，我们会修正为这个 alternative。」

这句话把 architecture 从品味变成 discipline。

---

Cheat sheet：22 个 Concepts 和 5 个 Decisions，按 Part 分组

Part	Concepts / Decisions
Setup	platform mapping、glossary、prerequisites、learning tracks、outcomes
Part 1	Concept 1 pattern selection before build；Concept 2 pattern assumptions；Concept 3 overshooting / undershooting
Part 2	Concepts 4–8 五问 decision tree；Concept 8.5 SDK primitives；Concept 8.6 operational envelope
Part 3	Concepts 9–13 五种 patterns
Part 4	Concepts 14–16.5 failure signals、targeted fixes、wrong tree、anti-pattern gallery
Part 5	Decisions 1–5：support、incident response、market research、enterprise onboarding、coding agent
Part 6	Concepts 17–18 cost/latency、composition
Part 7	Concept 19 connective tissue

Quick reference：五个问题，五种 patterns

Question	If yes	If no
Q1：solution path 能否提前定义？	去 Q2	去 Q3
Q2：workflow 是否固定？	sequential workflow	回到 adaptive patterns
Q3：task structure 是否能提前表达？	planning + ReAct execution	single agent + ReAct + tools
Q4：quality 是否比 speed 更重要，且 criteria 可检查？	添加 reflection layer	不添加 reflection
Q5：是否有 specialization/context/scale bottleneck？	multi-agent specialist system	保持 single/coordinator pattern

Design-review template（一页，可打印）

Task name：

Q1：solution path 是否已知？
Answer：
Evidence：

Q2：workflow 是否固定稳定？
Answer：
Evidence：

Q3：task structure 是否能在 execution 前表达？
Answer：
Evidence：

Q4：quality 是否比 speed 更重要，且 criteria 可检查？
Answer：
Criteria：

Q5：是否存在 specialization、context 或 scale bottleneck？
Answer：
Bottleneck：

Chosen starting pattern：

Why this pattern fits：

What complexity we intentionally did not add：

Deployment implications：

Eval signals：

Failure signal that would make us revise：

Fallback architecture if signal appears：

---

References

• Bala Priya C, "Choosing the Right Agentic Design Pattern: A Decision-Tree Approach," Machine Learning Mastery, May 15, 2026.
• OpenAI Agents SDK documentation and primitives referenced throughout.
• Agent Factory courses on Digital FTEs, operational envelopes, eval-driven development, and cloud deployment.

Flashcards Study Aid

本课有配套 flashcards，用来复习五问 decision tree、五种 patterns、failure signals、anti-pattern gallery 和 design-review template。先读正文，再用 cards 做 retrieval practice。