周读：《OpenAI Agents SDK》
阅读资料：OpenAI Official Documentation
周读日期：2026年11月13日
阅读主题：AI Agent架构、任务编排、工具治理、执行状态与生产系统可靠性
一家企业开发了一套AI客户服务系统。
最初，它只有一个简单任务：根据企业知识库回答用户问题。
后来，业务部门提出了更多要求。
客户询问产品参数时，需要读取技术资料。
客户咨询订单进度时，需要访问订单系统。
客户提出售后问题时，需要判断是否进入技术支持流程。
客户要求退款、变更订单或者修改交付地址时，系统还必须核验身份与权限。
于是开发团队想到一个办法：
建立多个Agent。
一个负责接待。
一个负责产品。
一个负责订单。
一个负责售后。
再增加一个负责审核。
看起来，只要把工作分给足够多的专业Agent，整个系统就会自然变得智能。
但真正上线以后，新的问题出现了。
客户提出一个涉及产品和订单的复合问题，接待Agent不知道应该交给谁。
产品Agent完成分析后，订单Agent重复读取同一份资料。
两个Agent对同一项业务条件给出了不同判断。
某个Agent调用工具失败后反复重试。
另一个Agent已经准备修改订单，却没有发现该操作需要客户确认。
最终，系统消耗了更多Token，产生了更多调用，响应时间更长，但业务结果未必更好。
这些问题并不是简单增加一个更强模型就能解决。
它们暴露的是：
多Agent系统最困难的部分，不是每个Agent是否足够聪明，而是整个协作过程是否具有清晰的控制权、责任边界和终止条件。
这正是OpenAI Agents SDK最值得研究的地方。
上一期《OpenAI Responses API》，我们讨论了模型怎样通过工具、状态和结构化输出参与真实业务。
本期继续深入：
当一个AI应用需要多个步骤、不同专业能力、工具执行与人工审批时，应该怎样把这些能力组织成一个可靠的执行系统？
一、Agents SDK为什么会出现
2025年3月11日，OpenAI发布Responses API及第一批Agent开发工具，其中包括Agents SDK。
当时Agent应用已经开始从简单对话转向复杂任务。
开发者需要处理的不再只是一次模型请求，而是：
模型决定是否调用工具。
应用执行工具。
工具结果返回模型。
模型继续处理。
必要时将任务转交其他Agent。
直到形成最终结果，或者进入需要人工干预的状态。
如果全部手工实现，开发者需要自行维护大量循环与状态逻辑。
例如：
什么时候再次调用模型？
什么时候结束？
工具调用失败怎样处理？
如何记录每一次Agent执行？
专业Agent之间怎样交接？
怎样在关键操作之前暂停？
OpenAI Agents SDK的核心目标，就是为这些反复出现的Agent运行机制提供一套轻量化的软件开发框架。
截至2026年11月，官方提供Python和TypeScript实现，支持Agent定义、工具、Handoffs、Guardrails、Sessions、Tracing及Human-in-the-Loop等机制。
SDK默认可以通过Responses API与OpenAI模型交互。
但它们位于不同的抽象层次。
Responses API主要提供模型交互与工具调用基础。
Agents SDK进一步管理这些交互如何构成持续运行的Agent流程。
因此，Agents SDK不是Responses API的简单替代品。
它更接近建立在模型交互能力之上的应用级编排工具。
二、什么才算一个Agent
今天人们很容易把任何使用大模型的程序都叫作Agent。
但这种定义过于宽泛。
一个能够回答问题的聊天机器人，不一定需要复杂Agent架构。
一个按照固定步骤依次调用三个API的程序，也未必需要让模型自主决定执行路径。
在OpenAI Agents SDK中，Agent是一个基本构件。
它通常包含：
模型。
Instructions。
Tools。
以及可选的Handoffs、Guardrails、Structured Outputs等运行配置。
但从系统设计角度看，更重要的不是这些字段。
而是：
模型是否被允许根据任务状态，在一定范围内决定接下来采取什么步骤。
例如：
读取用户问题。
判断是否需要查询产品数据库。
根据工具结果继续分析。
发现信息不足时要求补充。
必要时交给专业Agent。
最终返回结果。
这种能力与单次文本生成存在明显区别。
但也必须明确：
自主选择下一步，不等于拥有无限执行权限。
Agent能够提出行动意图，真正的业务操作仍然需要受到应用程序、工具权限和业务规则约束。
这一区别是整个Agent工程的基础。
三、Agent Loop：真正让Agent能够连续工作的机制
理解Agents SDK，最重要的技术概念之一是：
Agent Loop。
一次Agent执行通常不是只有一次模型调用。
模型可能先请求工具。
工具执行以后，模型继续处理。
随后又请求另一个工具。
直到任务完成、被交接、被中断，或者达到相应的执行限制。
Agents SDK通过Runner提供这样的运行循环。
开发者可以使用同步、异步或流式执行方式，并从运行结果中获得最终输出、执行项目、最后活动的Agent及必要的中断状态。
这听起来只是减少了重复代码。
但实际上，它引入了一个更重要的工程问题：
什么时候应该停止？
例如一个Agent试图获取某个产品的交货期。
第一次查询失败。
它重新查询。
第二次仍然失败。
它尝试其他工具。
随后又回到原来的工具。
如果缺乏明确限制，系统可能进入没有实际进展的执行循环。
因此生产环境中不能只依赖：
“让Agent自己判断什么时候完成。”
还需要设置：
最大运行轮次。
单次工具调用超时。
成本预算。
任务截止时间。
失败次数限制。
异常升级规则。
工具调用去重与重试策略。
SDK提供max_turns等控制能力，但它不等于自动建立完整的业务成本预算或故障恢复机制。
这些限制应结合应用自身的服务层实现。
Agent Loop解决的是连续执行能力。
Execution Policy决定连续执行应该受到什么约束。
两者缺一不可。
四、为什么大多数企业应该先做单Agent，而不是多Agent
Agent开发很容易陷入一种架构冲动。
一个研究Agent。
一个规划Agent。
一个执行Agent。
一个检查Agent。
一个总结Agent。
最终一个简单任务需要五个模型角色协作。
但更多Agent并不天然意味着更高质量。
每增加一个Agent，都可能增加：
模型调用。
上下文传递。
决策边界。
运行延迟。
调试复杂度。
评估成本。
甚至新的错误来源。
因此，真正合理的起点应该是：
Single Agent + Carefully Designed Tools。
例如一个企业技术支持助手，最初可能只需要：
一个Agent负责理解问题与组织答案。
一个产品参数查询工具。
一个技术文件检索工具。
一个订单查询工具。
一套明确的权限规则。
如果它已经可以稳定完成任务，没有必要因为“多Agent更先进”而继续拆分。
只有当任务确实出现明显的专业边界、控制权需求或上下文管理问题时，才考虑引入多个Agent。
这也符合OpenAI官方文档的建议：先完成一个可运行的Agent，再根据需要增加更复杂的编排模式。
复杂度应该由真实问题驱动，而不是由技术能力驱动。
五、多Agent真正的第一个问题：谁拥有最终控制权
OpenAI Agents SDK提供两种非常重要的协作模式：
Agents as Tools。
以及：
Handoffs。
它们看起来都能够让多个Agent协作，但运行语义不同。
理解区别，比记住接口名称更重要。
Agents as Tools：主管Agent始终负责最终结果
在这种模式下，主Agent可以把专业Agent当作工具调用。
例如：
主Agent收到客户问题。
它调用产品专家Agent分析技术要求。
再调用物流专家Agent判断运输条件。
最后由主Agent整合结果，对用户作出统一答复。
这里最重要的是：
主Agent始终拥有用户交互的控制权。
专业Agent完成的是相对明确的子任务。
因此，这种模式适合：
需要多个专家提供局部分析。
需要集中整合结果。
希望最终答案由统一角色审核与呈现。
例如企业准备一份复杂采购建议，主Agent需要结合技术、物流和商业资料，但最终仍应由一个统一的协调角色输出方案。
Handoffs：将当前控制权转交专业Agent
Handoffs则不同。
例如客户进入企业客服系统。
首先由接待Agent判断问题类型。
如果是订单查询，则将当前任务交给订单Agent。
如果是售后故障，则交给售后Agent。
完成Handoff以后，专业Agent成为当前活动Agent，并按照其自身配置继续处理。
这里发生的不只是“调用一个专家工具”。
而是：
Conversation Ownership发生变化。
因此，Handoffs更适合：
用户需要进入不同专业服务流程。
不同业务领域拥有不同的对话规则。
需要由某个专业Agent直接完成后续交互。
真正的架构判断，不是“要不要多Agent”。
而是：
专业Agent应该提供一个结果，还是接管一段任务？
六、Handoff不是权限转移，更不是责任自动转移
这一点特别容易被忽略。
在SDK中，Handoff可以改变当前活动Agent。
但这并不意味着：
新Agent自动获得新的业务授权。
例如接待Agent把客户转交给订单Agent。
订单Agent虽然负责订单相关对话，却不能因此读取所有客户订单。
它仍然需要通过业务系统验证：
用户身份。
订单归属。
访问权限。
允许执行的操作。
此外，Handoff还存在上下文边界问题。
默认情况下，接收Agent可能看到当前会话历史。
开发者可以使用Input Filter等机制控制传递内容。
但不能假设：
所有历史信息都应该自动交给每一个专业Agent。
例如售后Agent可能需要知道产品型号和问题描述。
却未必需要完整客户财务信息。
因此，设计Handoff时，应该同时明确：
Task Ownership。
谁负责当前任务？
Context Boundary。
哪些信息允许传递？
Authority Boundary。
可以执行哪些操作？
如果只设计了第一项，系统仍然可能存在明显的安全和隐私风险。
七、Tools与MCP：Agent能力越强，权限治理越重要
Agents SDK支持Function Tools、Agent Tools，以及与MCP服务器集成的工具能力。
工具让Agent能够超越单纯的语言生成。
例如：
查询产品数据库。
读取CRM。
搜索技术文件。
创建工作任务。
分析数据。
调用业务服务。
这些能力是Agent产生现实价值的基础。
但它们同时也是系统风险的主要入口。
假设一个Agent拥有：
读取客户记录。
修改客户状态。
发送邮件。
删除订单。
修改报价。
全部工具权限。
即使模型通常表现良好，这种设计仍然不合理。
因为工具列表代表的并不只是能力。
它同时代表：
Potential Authority。
更成熟的做法是将工具按照实际业务风险分级。
读取公开产品资料属于低风险查询。
读取客户私有信息需要身份与权限验证。
修改CRM属于业务写入。
发送正式报价可能涉及商业承诺。
删除订单或执行付款则可能具有不可逆后果。
因此Agent不应该默认获得全部能力。
它应在特定任务中，只看到和使用必要的工具。
SDK提供工具启用控制、Guardrails及审批机制等能力，但真正的资源级授权仍然必须由工具实现或业务系统执行。
Tool Visibility不是Authorization。
模型看不到某个工具，可以减少误用机会。
但模型能够看到某个工具，并不代表每一个工具参数或目标资源都已经获得授权。
八、Guardrails的价值，是把安全要求变成可执行边界
很多AI应用把安全要求写在Prompt里。
例如：
“不要泄露用户数据。”
“不要执行危险操作。”
“不要编造报价。”
这些指令当然有价值。
但如果系统只有Prompt，没有独立的检查机制，安全边界仍然比较脆弱。
Agents SDK提供Guardrails机制，用于检查输入、输出以及适用范围内的工具调用。
Input Guardrails可以对用户输入进行验证。
Output Guardrails可以对最终输出进行检查。
Tool Guardrails可以在部分自定义函数工具执行前后，对参数或返回结果进行验证。
但这里存在一个非常重要的技术细节：
这些Guardrails并不会自动在所有Agent、所有工具和所有中间步骤上执行。
根据官方文档，在Handoff链中，Agent级Input Guardrails主要作用于起始Agent的用户输入；Output Guardrails主要作用于最终产生输出的Agent。
部分工具类型也不经过自定义Function Tool的Guardrail执行路径。
因此：
不能因为在主Agent配置了一组Guardrails，就认为所有下游动作都受到同样保护。
尤其涉及写入、删除、发送和支付的操作，必须在业务工具内部保留独立的参数验证与权限校验。
另一个值得注意的细节是，输入Guardrails可以并行执行。在并行模式下，如果校验稍后失败，Agent可能已经开始消耗Token，甚至已经开始执行部分工具调用。
对于绝对不能在验证前发生的高风险操作，应采用阻塞式检查与工具执行前的强制授权控制。
这说明：
Guardrails不是装饰性的安全标签。
它们必须与真实执行顺序和权限体系结合起来设计。
九、Human-in-the-Loop：真正重要的是系统能够在哪里暂停
很多企业希望AI能够自动化工作，同时又要求：
关键操作必须有人审核。
这两种需求并不矛盾。
但需要真正的执行机制，而不是让模型在Prompt里说：
“请先获得批准。”
Agents SDK支持Human-in-the-Loop审批流程。
例如某个工具被配置为需要审批。
当Agent准备执行该工具时，运行可以产生待审批中断。
应用随后获取对应的Interruptions。
使用RunState保存可恢复的执行状态。
由具备权限的人员批准或拒绝。
然后继续原来的执行流程。
这里最重要的不是：
页面上出现了一个批准按钮。
而是：
审批必须成为业务执行路径中的真实关口。
例如AI生成了一封报价邮件。
销售经理需要确认：
客户。
价格。
交货期。
有效期。
是否包含不应作出的商业承诺。
批准以后，系统才允许发送。
但还必须继续考虑：
审批等待期间，报价是否已经过期？
客户状态是否发生变化？
审批人是否仍拥有权限？
如果恢复执行时业务条件改变，是否需要重新验证？
因此，生产系统不能只保存“有人点击过同意”。
还应该保存：
审批对象。
对应业务版本。
审批权限。
有效期限。
最终执行结果。
Human-in-the-Loop解决的是人工介入机制。
Business Approval Governance决定这次批准究竟在什么条件下有效。
十、Sessions与RunState：对话历史不是业务状态
Agents SDK提供Sessions，用于跨多次运行维护对话历史。
也可以通过应用自行管理消息，或者使用OpenAI服务端的相关会话延续机制。
这些方式能够帮助Agent保留上下文。
例如客户第一轮说：
“我需要一套工业干燥设备。”
第二轮补充：
“处理量每天20吨。”
第三轮又说：
“安装地点在欧洲。”
系统需要理解这些条件属于同一个需求。
但这里必须区分：
Conversation State。
和：
Business State。
对话历史记录的是：
用户和Agent曾经交流过什么。
业务状态记录的是：
真实订单当前是什么状态。
报价是否批准。
付款是否完成。
库存是否仍然可用。
这些事实不应该仅仅保存在Session中。
它们需要由具有明确数据一致性和权限机制的业务系统维护。
另外，Sessions与服务端响应延续机制具有不同使用方式和兼容约束，不能在同一次运行中任意叠加。
RunState则更侧重于保存中断后恢复执行所需的状态，包括审批等待等场景。
但即使SDK支持恢复，也不意味着它自动解决了完整业务流程的Exactly-Once执行问题。
特别是在发生外部副作用时，应用仍然需要：
请求唯一ID。
业务操作幂等。
状态核对。
恢复策略。
必要的补偿机制。
这一点与我们上一期《Designing Data-Intensive Applications》讨论的分布式系统问题完全一致。
十一、Tracing：必须看见Agent到底做了什么
普通聊天应用发生错误时，开发者通常可以查看：
输入Prompt。
模型输出。
但多Agent系统可能经历：
多个模型调用。
多个工具。
数次Handoff。
不同Guardrail判断。
人工审批。
执行恢复。
最终形成一个结果。
如果只保存最后一段回答，就很难定位失败原因。
Agents SDK提供内置Tracing能力，可以记录运行过程中的模型调用、工具调用、控制权交接与相关生命周期事件。
例如客户收到了一份错误的产品建议。
通过Trace，开发者可能发现：
接待Agent将问题路由到了错误的专业Agent。
或者产品Agent查询了旧数据库。
也可能是工具返回了正确结果，但总结Agent误读了参数。
这些问题需要完全不同的修复方式。
因此Tracing真正的价值不是：
让Dashboard更漂亮。
而是：
把难以观察的Agent协作过程转化成可检查的执行证据。
不过，Tracing本身也需要治理。
因为运行记录可能包含用户输入、工具参数、业务数据及模型输出。
官方SDK文档说明，Tracing在常见服务端运行环境中默认启用，但可按配置关闭或限制敏感数据的记录；使用相应Zero Data Retention配置的组织还需要考虑官方Tracing的可用性限制。
企业应根据自身数据控制要求决定：
记录哪些字段？
保留多久？
谁可以查看？
是否需要脱敏？
是否向第三方观测平台导出？
可观察性与数据最小化必须同时设计。
十二、Tracing不能代替Evaluation
这是AI工程实践中很容易混淆的两个概念。
Tracing回答：
某一次任务具体发生了什么？
Evaluation回答：
这类任务整体完成得怎么样？
例如某次Agent回答错误。
Trace可以帮助开发者发现工具调用顺序不合理。
但它不能直接证明：
新的Agent配置是否比旧版本整体更好。
这需要Evaluation。
对于一个多Agent业务系统，至少应该设计三类评估。
第一类是任务结果。
最终结果是否正确？
是否真正解决用户问题？
第二类是执行路径。
是否调用了适当工具？
是否发生了不必要Handoff？
有没有重复执行？
是否遗漏权限检查？
第三类是业务结果。
人工修改比例是否下降？
处理时间是否缩短？
客户投诉是否增加？
是否真的减少了工作负荷？
上线前应建立固定的Regression Dataset。
包含常见请求、复杂请求、边界条件以及恶意或异常输入。
每次调整Agent Instructions、工具定义、路由逻辑或模型版本后，都应该重新评估。
真正成熟的Agent工程，不是：
“这次演示成功了。”
而是：
我们可以证明，修改以后系统在关键场景下没有明显退化。
十三、多Agent系统真正需要警惕的，是错误在Agent之间被逐步放大
假设企业建立三层Agent系统。
第一个Agent负责理解客户需求。
第二个Agent负责技术分析。
第三个Agent负责生成商务建议。
客户原始询盘写：
“设备需要每小时处理10吨物料。”
第一个Agent误提取为：
“每天10吨。”
第二个Agent基于这个错误条件完成技术选型。
第三个Agent再基于选型结果生成一份看起来非常专业的建议。
每个Agent都可能在自己的局部任务中表现良好。
但最终答案仍然错误。
而且，多次专业化处理可能让结果显得更加可信。
这就是多Agent系统一个非常现实的风险：
Error Propagation。
错误在一次Handoff或工具返回中进入系统，随后不断被下游Agent当作事实使用。
所以关键业务事实不能只以自然语言摘要在Agent之间传递。
更稳妥的做法是：
采用结构化字段。
标记数据来源。
保留原始证据。
对关键参数执行确定性验证。
区分已确认事实与模型推断。
在重要决策前重新查询权威系统。
这说明，多Agent治理与数据治理并不是两件独立的事。
Agent协作越复杂，对事实来源与状态一致性的要求越高。
十四、一个完整案例：怎样设计企业AI技术支持Agent
假设一家工业设备制造企业希望建设AI技术支持系统。
用户可能询问：
产品参数。
故障判断。
安装条件。
保修状态。
备件。
订单。
这里首先需要回答：
是否真的需要多个Agent？
第一阶段可以先建立一个统一技术支持Agent，配备只读工具：
产品资料查询。
安装说明检索。
故障知识库查询。
订单状态查询。
并通过业务系统进行身份验证。
如果它能够稳定满足需求，就可以保持单Agent架构。
当真实测试发现：
订单问题与技术问题具有不同的工作流程、权限和审核要求，
才考虑引入专业Agent。
例如：
Triage Agent
负责识别任务类型，不直接修改业务数据。
Technical Support Agent
负责读取技术资料并提出技术建议。
Order Support Agent
负责在授权范围内查询订单。
Service Coordinator
负责整合结果或管理需要多人参与的流程。
其中不一定每个角色都要成为独立Agent。
如果技术支持只是为最终答复提供一个局部分析结果，可以通过Agents as Tools方式调用。
如果客户已经进入独立的订单服务流程，可以考虑Handoff。
而真正修改订单、创建售后工单或发送重要承诺时，必须进入业务工具的权限检查与必要审批。
这才是一套由业务需求决定的Agent架构。
而不是为了展示多Agent能力而增加角色。
十五、Agent生产系统应当具备哪些最小治理能力
如果将这套技术真正用于企业，我认为至少需要建立六个治理边界。
第一，任务边界。
Agent可以解决什么，不能解决什么？
第二，数据边界。
它可以读取哪些数据？哪些数据必须实时查询？哪些属于未经验证的外部信息？
第三，工具边界。
哪些工具可以调用？哪些参数必须校验？哪些操作涉及业务写入？
第四，权限边界。
谁授权了这次操作？授权对象和范围是什么？是否需要人工确认？
第五，执行边界。
最多可以运行多少轮、消耗多少资源？失败以后怎样停止、重试或恢复？
第六，验证边界。
怎样确认结果正确？怎样记录执行过程？如何检测版本更新造成的退化？
这六个边界不能全部依靠Prompt实现。
其中大量要求需要通过：
代码。
数据库。
权限系统。
工具实现。
运行配置。
评估系统。
以及组织流程落实。
这也是为什么Agents SDK虽然降低了Agent编排难度，却不会自动把一个实验程序变成成熟的企业生产系统。
十六、AI Agent项目真正应该怎样分阶段推进
对于首次建设Agent的企业，我更推荐以下四个阶段。
第一阶段：证明单任务价值
选择一个明确、可评估、错误成本可控的任务。
例如根据产品知识库生成技术支持建议。
先建立单Agent与少量只读工具。
记录人工基线。
确认AI是否确实改善质量或效率。
第二阶段：建立执行可观察性
加入Tracing、结构化结果、成本统计与固定评估集。
开始记录最常见失败。
确认问题来自：
模型理解。
数据。
工具。
上下文。
还是业务规则。
第三阶段：增加受控业务行动
当系统需要创建CRM任务、生成报价草稿或者修改业务状态时，增加工具权限控制、幂等和人工审批。
先采用小范围运行。
明确回滚与故障处理。
第四阶段：根据真实瓶颈引入多Agent
只有当单Agent无法合理维护不同专业流程，或者复杂任务确实需要明确交接时，才进一步增加Handoffs或Agents as Tools。
这时需要重新评估：
任务成功率是否提高？
延迟是否增加？
成本是否合理？
问题定位是否更加困难？
是否出现新的Agent间错误？
如果多Agent方案没有改善结果，就没有必要保留它。
架构复杂度必须以实际收益证明自己。
十七、本周实践：完成一份Agent Architecture Decision Record
这一周不必马上开发复杂的多Agent系统。
选择一个真实业务任务，为它写一份简短的架构决策记录。
只回答八个问题。
1. User Task
用户究竟希望完成什么？
2. Success Criterion
怎样证明任务已经正确完成？
3. Agent Boundary
是否需要Agent？能否用确定性流程解决？
4. Tool Design
需要哪些只读或写入工具？权限由谁验证？
5. Orchestration
单Agent是否足够？如果需要多Agent，选择Agents as Tools还是Handoffs？为什么？
6. Guardrails & Approval
哪些检查必须在工具执行前完成？哪些操作需要人工审批？
7. State & Recovery
对话如何延续？真实业务状态在哪里？中断后怎样恢复？
8. Tracing & Evaluation
怎样重现一次失败？怎样证明新版本比旧版本更好？
如果这些问题无法回答，暂时不要增加更多Agent。
先把一个小型系统设计清楚。
因为真正困难的通常不是让五个Agent一起工作。
而是：
让五个Agent在出错时，仍然知道谁应该负责、哪里应该停止。
十八、从Responses API到Agents SDK，我们真正增加了什么
将前两期周读放在一起，可以得到一个清晰的技术关系。
Responses API帮助开发者组织：
模型输入。
工具调用。
结构化输出。
多轮上下文。
模型与外部能力之间的交互。
Agents SDK进一步帮助开发者组织：
Agent运行循环。
专业能力委派。
控制权交接。
Guardrails。
Sessions。
人工审批。
Tracing。
但必须注意：
这些能力解决的是Agent编排中的常见问题。
真正的企业生产系统还需要：
业务数据库。
身份与访问控制。
一致性与幂等。
运行资源限制。
安全审计。
长期工作流恢复。
质量评估。
数据生命周期治理。
因此，AI应用开发的技术链条正在变得清楚：
Model Capability
决定模型能够理解和生成什么。
Responses API
提供模型与工具交互的基础。
Agents SDK
提供Agent执行与编排能力。
Application Infrastructure
负责真实数据、权限与业务规则。
Governance & Evaluation
负责持续监督系统行为和结果。
真正的系统可靠性来自这些层次共同工作。
不能把其中任意一层误认为完整答案。
十九、我对Agents SDK最大的重新理解：Agent架构首先是控制权设计
第一次接触Agents SDK时，人们最容易关注：
怎样创建Agent。
怎样增加Tools。
怎样使用Handoffs。
怎样运行多个专业角色。
但真正阅读官方文档以后，会发现更值得研究的是：
Control Ownership。
谁当前拥有任务？
谁能够调用什么工具？
谁决定是否转交？
谁验证参数？
谁承担审批？
谁记录执行结果？
谁在失败后恢复？
谁决定最终任务是否完成？
这些问题听起来不像人工智能算法。
却直接决定Agent能否被用于真实组织。
这也让Agents SDK与我们前面阅读的几本书建立了联系。
《High Output Management》讨论管理者怎样提高组织产出。
《Good Strategy/Bad Strategy》讨论怎样让行动围绕正确方向保持一致。
《Designing Data-Intensive Applications》讨论分布式系统怎样维护状态和处理故障。
《Responses API》讨论模型怎样进入真实软件流程。
而Agents SDK进一步提出：
当越来越多步骤由AI自主选择时，怎样让整个执行系统保持清晰、受控和可追溯。
所以多Agent架构本质上不仅是软件架构。
它还具有明显的组织管理特征。
专业分工。
授权。
交接。
监督。
评估。
升级。
责任。
但也必须避免直接把Agent当作具有人类责任能力的员工。
AI可以承担被授权的任务执行。
最终的业务责任仍然需要由人和组织明确承担。
结语：AI Agent真正的成熟，不是能独立完成多少任务，而是能在多大程度上被可靠地托付
AI Agent的发展，很容易让人产生一种兴奋感。
以前模型只能回答问题。
现在能够调用工具。
能够读取文件。
能够使用应用。
能够生成代码。
能够在多个步骤之间作出选择。
甚至能够与其他Agent协作。
这些能力确实正在改变软件系统。
但企业真正部署Agent时，最重要的问题已经不是：
它还能多做什么？
而是：
我们究竟可以放心让它做什么？
如果一个Agent能够自动生成报价，但不能判断数据是否过期，就不应该获得未经审核的正式报价权限。
如果一个Agent可以修改CRM，但无法保证重复请求不会产生重复记录，就还没有达到可靠业务执行的要求。
如果多个Agent能够快速交换结果，但错误数据会在它们之间不断传播，那么增加协作反而可能放大风险。
如果系统无法解释一次失败究竟发生在哪个步骤，那么它的复杂度就已经超过了当前治理能力。
所以我认为，Agents SDK最值得带走的一条思想不是：
“让AI拥有更多自主权。”
而是：
“为AI的自主行为建立明确边界。”
真正成熟的Agent系统，应当知道：
什么时候继续。
什么时候调用工具。
什么时候转交任务。
什么时候请求批准。
什么时候停止。
什么时候承认无法完成。
以及失败以后怎样恢复。
这并不意味着压制AI能力。
恰恰相反。
只有具备可靠的控制机制，组织才敢把更重要的任务交给AI。
从这个意义上看：
Agent能力的上限，取决于模型、工具和任务设计。
但Agent能够承担多少真实业务责任，取决于整个系统的治理成熟度。
2026年，我们已经不缺能够演示复杂任务的Agent。
更值得长期建设的，是：
能够被观察、被评估、被纠正，也能够在必要时安全停止的Agent。
这才是AI从实验走向生产、从辅助走向可靠协作的关键。
本期互动
打开一个正在使用的AI工作流。
假设它明天发生三件事：
一个专业Agent把任务转交给错误的Agent。
一个工具请求超时，但业务操作已经执行成功。
一个Agent准备修改客户数据，却没有获得适当授权。
系统会在哪里发现这些问题？
谁能够停止执行？
错误发生以后，是否有足够的证据还原整个过程？
如果没有明确答案，那么下一阶段最值得增加的，可能不是更多Agent。
而是：
Control、Observability与Recovery。
本期官方参考资料
以下均为OpenAI官方技术资料。Agents SDK持续更新，具体接口与行为应以部署时使用的SDK版本及对应文档为准。
OpenAI：Agents SDK官方总览
OpenAI：Agents SDK Python
OpenAI：Agents SDK TypeScript
OpenAI：Python Quickstart
OpenAI：Agent Orchestration
OpenAI：Handoffs
OpenAI：Tools
OpenAI：Guardrails
OpenAI：Human-in-the-Loop
10. OpenAI：Sessions
11.OpenAI：Tracing
12.OpenAI：New Tools for Building Agents，2025年3月11日
说明：本文对Agent、Handoffs、Guardrails、Sessions、Tracing与审批流程的技术描述依据官方文档；关于工业设备技术支持、组织分工、分阶段部署及治理机制的案例属于工程实践性延伸，不应理解为OpenAI对特定企业系统的正式架构要求。
下期预告
周读：《Building Applications with AI Agents》
下一期，我们将从Agents SDK的具体机制，进一步进入完整Agent应用的架构设计。
如果本期重点讨论：
Agent怎样运行、使用工具、转交任务并接受治理？
那么下一期将继续回答：
一个能够在真实企业环境中长期运行的Agent应用，究竟应该具备哪些系统能力？
我们将重点讨论：
Agent应用的任务边界。
Workflow与Agent的选择。
工具与业务系统集成。
短期上下文和长期记忆。
检索与知识来源。
执行状态。
评估体系。
人机协作。
生产部署和运行成本。
并通过一个完整企业应用场景，说明怎样从简单原型逐步建设一个可靠的Agent系统。
真正的Agent Engineering，不是让模型拥有更多工具，而是让模型、工具、数据、流程和人共同构成一个能够稳定交付结果的系统。
标签
OpenAI Agents SDK,OpenAI,AI Agent,Agent Engineering,多Agent系统,Multi-Agent,Handoffs,Agents as Tools,Tool Calling,MCP,Guardrails,Human-in-the-Loop,Tracing,Sessions,Agent Orchestration,Agent Governance,AI应用架构,企业AI,工作流自动化,生产系统,AI安全,系统可靠性,终身学习,周读
推荐阅读:
周读：《OpenAI Responses API》·OpenAI Official Documentation
周读：《Designing Data-Intensive Applications》