AI agent 技术栈包含彼此独立的推理、工具、身份、记忆、执行、应用基础设施和遥测层。真正有用的边界并不是厂商划分的产品类别，而是一个系统的职责终点，以及另一个系统能够验证其结果的起点。
小型应用可以在一个进程中实现多个层次。只要授权、状态、重试和限制仍有明确的责任方，这种做法没有问题。
技术栈全景图
flowchart TD
U[User goal] --> A[Agent loop and model]
A --> T[Tools and integrations]
P[Identity and policy] --> T
T --> R[Execution runtime]
T --> B[Application backend]
M[Memory and durable state] <--> A
M <--> R
R --> B
A --> O[Telemetry and evaluations]
T --> O
R --> O
B --> O
这并不是一条请求流水线。工具可以直接调用后端，工作流可以先读取记忆再选择工具，而遥测会观察每条分支。图中的箭头表示需要用明确契约约束的依赖关系。
推理与编排
模型负责理解目标并提出操作方案。Agent 循环决定模型能获得哪些上下文和工具，执行选中的调用，记录结果，并在适当的时候结束运行。模型选择会影响行为，但超时、步骤上限和终止条件应由循环负责。
这些限制应放在提示词之外。要求模型在十次调用后停止，不如让运行时直接拒绝第十一次调用可靠。
工具与集成
工具将 agent 的决策转换为外部能力。工具应该表达具体任务、校验输入、返回稳定结果，并隐藏调用方不应接触的凭据。MCP 通过其工具规范提供标准的发现和调用契约。
协议不会决定是否应该提供 delete_workspace，也不会决定该操作是否需要审批。这仍然是应用和策略层的决策。REST 转 MCP 教程介绍了如何在封装现有 API 时保留这条边界。
身份与策略
身份回答“谁在执行操作”，策略回答“这个身份当前可以做什么”。即使 MCP 网关提前过滤了工具，拥有数据的下游服务仍必须执行最终的授权规则。
这一层还负责在破坏性操作或产生费用之前取得审批。工具调用完成后的审批只是审计记录，不是准入关卡。
记忆与持久状态
记忆让后续模型调用能够获得相关信息。持久状态记录已经完成的工作、待办事项和外部影响。将两者混在一起会给恢复带来麻烦，因为检索到的上下文并不是操作账本。
向量索引可以帮助检索笔记，但不能成为付款已完成的唯一记录。Agent 记忆实用指南分别讲解了工作上下文、语义记忆、情景历史和工作流状态。
执行运行时
运行时负责执行 agent 循环和生成的代码。它可以提供队列、检查点、重试、沙箱、网络控制和生命周期限制。持久执行与沙箱解决的是不同问题：前者让任务在中断后继续，后者限制任务能访问的资源。
Temporal 对持久执行的介绍指出，持久执行会在故障发生时保留工作流进度。沙箱仍需分别设置进程、文件系统、网络、密钥和时间边界。
应用基础设施
Agent 构建的应用仍然需要 Postgres、对象存储、身份验证、托管、邮件、搜索和外部 API。Agent-native 基础设施通过结构化配置流程和限定到项目范围的凭据来提供这些资源。
Cohesivity 位于这一层。它让 coding agent 能在一个项目上下文中使用支持的后端资源，同时将上游提供商凭据保留在服务端。更全面的 AI agent 基础设施指南介绍了这一层与技术栈其他部分的连接方式。
遥测与评估
遥测应将用户目标、模型输出、工具决策、策略结果、执行过程和后端影响串联到一条追踪记录中。评估则通过重放固定任务，在部署前发现行为变化。
OpenTelemetry 的 GenAI 语义约定定义了模型和 agent 活动的通用属性。应用仍需提供稳定的租户、agent、操作和策略标识符，才能把这些活动与实际影响对应起来。
需要重点检查的职责边界
以下三种职责边界经常引发问题：
- Agent 循环和工具封装层同时进行重试，导致一次逻辑操作产生多次写入。
- 网关过滤了工具，但下游 API 信任权限宽泛的凭据，没有对具体资源执行授权。
- 记忆层保存了操作摘要，却没有持久操作记录表明该操作是否完成。
画出一条工作流，并为每项行为指定唯一责任方。下方的提示词可以在不修改代码的情况下找出无人负责或重复负责的部分。