Agent 架构

Q3FSM 状态机分哪几部分？如何代码实现？

参考答案

FSM（有限状态机）的形式定义是一个五元组：

• Q — 状态集合：系统全部合法状态
• Σ — 输入 / 事件集：触发转移的外部输入
• δ — 转移函数：δ(状态, 事件) → 新状态
• q₀ — 初始态
• F — 终态集

工程实现在五元组之外再补两个构件。其一是动作 / 副作用，按挂载位置分两种机型：Mealy 机把动作挂在转移边上（出边动作，同一状态因不同事件触发不同副作用），Moore 机把动作挂在状态入口（入态动作，副作用集中、易测试）。其二是 guard 条件：转移上的布尔谓词，事件到达且 guard 为真才允许转移，用于表达"重试次数未超限才回到执行态"一类约束。

Python 实现按复杂度分三档。第一档：dict 转移表，把 δ 直接写成 {(state, event): next_state} 的字典，配一个 step() 函数，状态与事件少时零依赖、一眼看全：

# δ: (state, event) -> next_state，转移表即状态图本身
TRANSITIONS = {
    ("idle",      "user_input"):  "planning",
    ("planning",  "need_tool"):   "calling",
    ("planning",  "can_answer"):  "answering",
    ("calling",   "tool_result"): "observing",
    ("observing", "need_more"):   "calling",     # 条件回边
    ("observing", "enough"):      "answering",
    ("answering", "finish"):      "idle",
}

def step(state: str, event: str) -> str:
    key = (state, event)
    if key not in TRANSITIONS:
        raise ValueError(f"非法转移: {state} x {event}")
    return TRANSITIONS[key]

第二档：Enum + match，把状态、事件、guard 与副作用全部显式写出，适合 plan → execute → verify → done 一类任务编排：

from enum import Enum, auto

class State(Enum):
    PLAN = auto(); EXECUTE = auto(); VERIFY = auto()
    DONE = auto(); FAILED = auto()          # DONE/FAILED ∈ 终态集 F

class TaskMachine:
    MAX_RETRY = 3

    def __init__(self):
        self.state = State.PLAN              # q0 初始态
        self.retries = 0

    def on_event(self, event: str) -> State:
        match (self.state, event):
            case (State.PLAN, "plan_ready"):
                self.state = State.EXECUTE
            case (State.EXECUTE, "result"):
                self.state = State.VERIFY
            case (State.VERIFY, "pass"):
                self.state = State.DONE
            case (State.VERIFY, "fail") if self.retries < self.MAX_RETRY:
                self.retries += 1            # guard 为真：重试回边
                self.state = State.EXECUTE
            case (State.VERIFY, "fail"):
                self.state = State.FAILED    # guard 为假：进失败终态
            case _:
                raise ValueError(f"非法转移: {self.state} x {event}")
        return self.state

第三档：transitions 库。声明式定义状态与转移，原生支持 before/after callback（对应 Mealy 出边动作）、on_enter（对应 Moore 入态动作）、conditions guard，以及 HierarchicalMachine 层级状态机与状态图导出。状态、事件数量增长，或需要在 code review 时核对状态图，引入此档。

Agent 场景中 FSM 出现在三个典型位置：对话流程控制（槽位收集、多轮确认）、任务编排（plan → execute → verify → done）、工具调用循环（calling → observing → answering，即图 1）。

加分点

追问预判

Q4为什么选择 ReAct，而不是纯 Chain 或 Tool Use？

参考答案

ReAct（Yao et al., 2022）的核心是把 Reasoning 与 Acting 交织进同一循环：Thought 决定下一步动作，Action 执行工具调用，Observation 把结果送回推理，推理再据此修正方向。三种模式的本质差异在于"路径在什么时候被决定"：

ReAct 的收益由"环"带来：动态决策（步数未知也能推进）、错误恢复（一条路失败后换工具、换查询重试）、可观测性（推理轨迹逐轮留痕，便于调试与审计）。代价同样由"环"带来：多轮交互的延迟、token 用量随轮数倍增、循环失控需要 max_iterations 一类硬上限兜底。

面试作答的正确顺序是先确认任务形状，再给结论：步骤可预枚举 → Chain 更便宜更稳；单步查询 → 一次 Tool Use 足够；开放式多步、步数未知 → 才轮到 ReAct loop。

加分点

追问预判

Q6多 Agent 框架怎么设计？划分 Agent 的依据是什么？

参考答案

多 Agent 设计沿三条正交轴展开，三轴独立选择、组合成最终架构：

• 拓扑：supervisor（协调者）星形 / hierarchical 树形 / swarm 任意图 + handoff（交接）；
• 协调：中心调度（supervisor 统一分派与汇总）vs 去中心交接（执行中把控制权 handoff 给下一个 Agent）；
• 通信：共享 state vs 消息传递，并按上下文隔离档位决定向对方暴露多少中间态。

划分 Agent 的依据按优先级排列为四条：

1. 按上下文隔离需求（最重要）：subagent 拥有独立上下文窗口，长流程的中间产物不污染主线，主 Agent 只接收浓缩结论；
2. 按领域 / 职责：检索、写作、审校各成一职，单一职责降低提示词复杂度；
3. 按工具集：每个 Agent 只挂自己用得到的工具，缩小决策空间、降低误调用率；
4. 按模型能力分层：orchestrator 用强模型做规划与汇总，worker 用便宜模型跑量。

工程标杆是 Anthropic 的多 Agent 研究系统：orchestrator-worker 拓扑，在内部研究评测上比单 Opus 4 提升 90.2%，代价是约 15 倍 token 消耗。该系统给出的另一条硬经验：委派指令必须包含目标、输出格式、工具指引、任务边界四要素，缺失任何一项都会导致 subagent 重复劳动或偏离主题。

加分点

追问预判

Q12LangChain 和 LangGraph 的区别？

参考答案

两者在 2025-10-22 同日发布 1.0 GA，分工是高层 API vs 低层运行时。LangChain 1.0 提供 create_agent + middleware 体系（HITL 人在回路、对话摘要、PII 脱敏等横切能力以中间件形式插入 agent loop）；其 LCEL 链是静态的 RunnableSequence，执行顺序在构造期定死，无法表达回边。LangGraph 1.0 提供 StateGraph 运行时：图 = 节点 + 边 + 共享 state（TypedDict + reducer，reducer 即"合并函数"，定义并发写入同一 key 时的合并协议）；条件边支持分支与循环；checkpointer 在每个超步后按 thread_id 持久化 state 快照，由此支撑断点续跑、time-travel 调试、HITL interrupt（checkpointer 也是 01 章跨会话记忆的承载机制）。

两者的关系：create_agent 底层就是 LangGraph runtime——LangChain 是快速路径、LangGraph 是精控路径，不是两条竞争路线。选型规则：标准 tool-calling agent → create_agent；自定义控制流、长时运行、需要持久化 → 直接写 LangGraph；复杂长程任务 → deepagents（2025 下半年发布，create_agent 之上的全装 harness：write_todos 任务规划、spawn subagent、虚拟文件系统、SKILL.md 技能装载）。

加分点

追问预判