Agent 架构师：企业级智能体系统的四个确定性支点

Agent 架构师与传统软件架构师的设计对象不同。后者的产出是服务边界和模块接口；前者的产出是Agent 拓扑、委派边界与信任层级，其关键判断从“哪些服务需要分离”变为“哪些任务适合委派、哪些必须自动化、哪些永远不能交给模型”。企业级 Agent 系统的失败很少因为模型不够强，而是因为架构师没有在概率性智能外面钉下足够多的确定性支点。以下四个支点，决定了系统能否从 PoC 走进生产。

一、拓扑：图结构胜出的原因是可检查的状态

2026 年的企业实践已经收敛：图结构编排取代了自由的 ReAct 循环和扁平的对话流，成为主导模式。原因不在性能，而在可检查性：节点是 Agent 或函数，边是显式转移，条件分支和循环在图上可见，类型化状态对象随图流动，checkpoint 才有附着点。集中式 Supervisor 适合需要强审计的流程，去中心化 Swarm 适合对话式交接，分层图则在两者之间取得控制力与成本的平衡。

from typing import TypedDict, Literal

class TriageState(TypedDict):
    query: str
    domain: str | None
    result: dict | None
    approved: bool

def route(state: TriageState) -> Literal["billing", "technical", "human"]:
    if state.get("approved") is False:
        return "human"
    return "billing" if "invoice" in state["query"] else "technical"

graph.add_conditional_edges("triage", route,
    {"billing": "billing_agent", "technical": "tech_agent", "human": "human_gate"})

架构师在这里的决策不是“用哪个框架”，而是哪些转移必须硬编码、哪些可以留给模型。高风险路由（退款、权限变更）应该走 human_gate，而不是依赖 Agent 的自我判断。

二、持久化：断点续跑不是功能，是执行契约

长时运行的 Agent 必须被当作有状态的服务进程，而非无状态的请求处理函数。一个处理 400 份文档的 Agent 在第 301 份崩溃时，没有 checkpoint 就意味着从零重来。LangGraph 的生产级差异化正在于此：持久化状态而非仅协调，使中断、恢复和人工介入成为一等能力。Checkpoint 的粒度是架构决策——太粗会丢失进度，太细则拖累性能，每 N 步落盘是在持久性与开销之间的工程折中。

def process_with_checkpoint(items, store, task_id):
    state = store.load(task_id) or {"done": 0, "results": []}
    for i in range(state["done"], len(items)):
        state["results"].append(agent.analyze(items[i]))
        state["done"] = i + 1
        if (i + 1) % 30 == 0:          # 每 30 项落盘
            store.save(task_id, state)
    store.save(task_id, state)
    return state["results"]

更关键的是 Delegated Approval：走到审批节点时，Agent 在原地暂停，完整的推理链、工作记忆和 tool call 历史全部保留，等待期间消耗零计算资源，恢复时从精确断点继续而非重建上下文。架构师必须把“暂停与恢复”设计为执行模型的原生语义，而不是事后用 webhook 拼凑的补丁。

三、策略执行点：权限边界不能存在于模型的“理解”里

Agent 安全的首要原则：把 LLM 当作不可信的规划器，把运行时当作可信计算基。提示词、System Message 和模型的自我约束都不是权限边界，因为它们都可以被后续输入覆盖或绕过。企业级架构必须在编排器与每一次模型/工具调用之间放置一个策略执行点（PEP），对工具调用做出 ALLOW / DENY / REQUIRE_APPROVAL 的确定性裁决。策略应放在 Agent 外部，策略变更一次生效，整个 Agent 舰队立即继承新规则。

def authorize(tool: str, args: dict, ctx: dict) -> str:
    policy = policy_engine.evaluate(
        principal=ctx["agent_id"], action=tool,
        resource=args.get("target"), context=ctx
    )
    if policy.decision == "DENY":
        raise PermissionError(policy.reason)
    if policy.decision == "REQUIRE_APPROVAL":
        return "pending"
    return "allowed"

策略执行点还必须承担成本熔断与循环检测：相同工具、相同参数、相同错误连续出现即判定为循环；单条链路累计成本超过预算阈值即终止。OWASP Agentic Top 10（2026）已将熔断和事务性回滚列为 Agentic 工作流的强制要求。

四、评估闭环：生产失败必须成为下一次发布的门禁

Agent 的可观测性不能停留在“记录发生了什么”。OpenTelemetry GenAI 语义约定已经覆盖 LLM 调用和工具执行，但规划、推理、安全监控、Agent 间委派和记忆管理这五个编排阶段仍然缺乏 span 级表示。架构师需要在标准语义之上补充编排语义，更重要的是把评估嵌入 CI 门禁：一次生产失败 → 一条 trace → 一个测试用例 → golden dataset → 发布门禁，每次 prompt 或模型变更都跑一遍回归。没有这条闭环，Agent 的“迭代”就只是盲目的版本滚动。

结语

Agent 架构师的核心产出不是更多的 Agent，而是让 Agent 的行为可检查、可暂停、可回滚、可拒绝的边界结构。拓扑决定控制流是否可见，持久化决定任务能否存活，策略执行点决定模型不能越过的线在哪里，评估闭环决定系统是否在真正变好。四个支点缺任何一个，企业级 Agent 都只是“能演示”，而不是“敢托管”。