架构篇导读

过去一年，AI 原生应用的构建起点发生了位移。模型不再只是被应用调用的生成引擎，而是能够维持任务状态、分解目标、调用工具并根据执行反馈调整行为的执行主体。Codex、Claude Code、Qoder 等 Coding Agent 率先在软件研发中验证了这种形态：它们不只给出代码建议，还读取代码仓库、维护任务计划、修改文件、运行终端与测试，并在长时间任务中持续接受人的引导。

模型获得更大的任务自主权，并不意味着模型本身即构成 Agent。任务越长、工具越多、环境影响越大，模型之外的工程系统就越关键。上下文组织、任务状态、工具控制、环境隔离、失败恢复、结果评估与风险约束共同构成 Harness，Agent 由 Model 与 Harness 共同构成。这一判断改变了架构对象：企业需要设计的不再是一次模型调用，而是一个跨越认知、状态、执行、控制与持续改进的完整系统。

架构篇处理生命周期五阶段中的第一个阶段。它给出判断与边界：采用什么应用形态、授予多大自主权、哪些能力自建、哪些由共享平台提供、什么结果构成完成。这些边界若推迟到构建阶段再确定，后续运行、治理与调优将出现混乱。

对应章节	主线	架描述
第 1 章	应用构建范式	应用形态如何演进、Agentic Application 的定义与边界、企业成熟度如何判定。
第 2 章	建立架构	系统由什么组成、组件在哪里运行由谁负责、如何从决策走向运行并被改进。

第 1 章解决对象界定。应用形态不是一条简单的替代链，Workflow 与 Agent 将长期共存；Single-Agent 沿时间跨度扩展为 Long-Horizon Agent，沿协作结构扩展为 Multi-Agent，两者可独立采用，也可组合使用，但都不是所有应用必经的升级阶段。成熟度同样不由产品名称决定，判据是自主性能否与任务风险相匹配，并选择成本与风险可接受的最低充分架构。

第 2 章解决结构落位。三个视图互不推导：组件视图避免能力遗漏，平台视图避免责任混乱，生命周期视图避免把一次演示误判为可运营系统。同一个 State Store，在组件视图中是任务事实的持久化能力，在平台视图中属于数据与资源面，在生命周期视图中则是运行阶段产生、调优阶段被反复读取的证据来源。讨论任何能力时先确认其所处视图，是这套参考架构可用的前提。

两章构成前后依赖，建议顺序阅读。本篇需要带走的判断有两条：形态与成熟度不由产品名称决定；架构的目的不是把系统做大，而是为每一项被授予的自主性建立对等的执行、观测、安全与评估能力。