1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊而是真正在查文档、调 API、写代码、改配置、再验证——一整套闭环动作。我去年就带着团队跑过这样一个销售线索清洗CRM 同步邮件模板生成的长流程任务。前二十分钟一切丝滑模型响应快、工具调用准、上下文记得牢。但到了第三十五分钟事情开始不对劲它突然把上周五的客户电话记录当成今天的会议纪要发给了销售总监接着又在调用 Salesforce API 时把本该更新的 lead status 错写成 delete最后干脆卡住返回一串毫无逻辑的 JSON 字段连错误提示都懒得给。我们翻日志、看 trace、重放 prompt——全无头绪。直到把整个 session 的 token 流水倒出来一行行数才发现它的上下文窗口早被撑爆了。模型不是“出错了”是“被迫失忆”——它把最开始的用户原始需求、认证凭证、API 文档摘要这些关键信息全当垃圾给挤掉了。没有崩溃没有报错只有安静的、昂贵的、不可逆的失效。Anthropic 在 4 月 8 日发布的Claude Managed Agents表面看是一次常规的产品发布支持 Notion、Asana、Rakuten 等客户快速接入沙箱执行、会话持久化、凭据隔离、checkpoint 恢复……媒体通稿里全是“十倍提速”“企业级安全”“开箱即用”。但真正戳中痛点的是它把session会话从模型上下文里彻底剥离出来变成一个独立、持久、可查询的事件日志event log。这不是功能叠加是架构范式的切换。就像 90 年代操作系统把硬件资源虚拟化让应用不再直接操作内存地址和磁盘扇区一样Managed Agents 把“状态”这个最易出错、最难调试、最影响扩展性的部分从模型的“脑容量”里硬生生抽出来放到一个可靠、可审计、可回溯的外部系统里。模型只负责“思考”——输入 prompt输出 actionHarness执行器只负责“干活”——接收指令调用工具返回结果Sandbox沙箱只负责“隔离”——提供干净环境销毁不留痕。三者之间靠明确定义的接口通信互不耦合。这种解耦让整个系统第一次具备了真正的工程韧性。你再也不用担心一次超长会话会把模型搞崩也不用为恢复一个中断的流程而重写半套逻辑。它解决的不是一个具体功能问题而是所有严肃 Agent 应用落地时那个反复出现、反复踩坑、反复重写的底层顽疾。这个变化之所以重要是因为它直指当前 Agent 开发中最隐蔽也最致命的成本黑洞调试成本与状态管理成本。一个典型的 LangChain 或 CrewAI 项目70% 的开发时间花在处理 context overflow、session 断连、tool call 失败重试、凭据泄露防护、trace 难以对齐这些“非智能”问题上。而 Managed Agents 把这些统统收编进平台层开发者只需专注定义“这个 Agent 应该做什么”——用 YAML 描述它的角色、工具、规则、guardrail剩下的交给 Anthropic。这背后是认知负荷的转移从“我怎么让模型不丢状态”变成“我怎么描述清楚业务意图”。对于 Notion 团队来说这意味着他们能用一周时间就把一个跨数据库、跨文档、跨协作流的复杂工作流代理上线对于 Rakuten 的销售运营团队意味着他们可以按需创建、复制、下线不同场景的 Agent而不用每次重建一套状态同步机制。它不创造新能力但它让已有能力变得可规模化、可维护、可交付。这才是“已经 going to zero”的真实含义——不是技术不值钱而是“自己造轮子”的必要性正在归零。当你发现 AWS、Google、Microsoft 都已提供同质化极高的托管 runtime而开源社区 Daytona、Kubernetes SIG 的 agent-sandbox 项目正以亚秒级启动速度逼近生产标准时你就明白runtime 层的价值锚点已经从“能不能做”彻底转向了“谁来做更省心、更合规、更无缝”。2. 架构拆解为什么是 Session-as-Event-Log而不是别的2.1 核心分层Harness、Session、Sandbox 的三角关系Anthropic 的 Managed Agents 架构绝非简单地把现有 LangChain 代码扔进一个云服务里。它是一次有意识的、面向生产环境的分层重构其核心在于将传统 Agent 系统中纠缠在一起的三个关键概念——执行逻辑、状态存储、运行环境——彻底解耦并赋予它们各自清晰的边界与职责。这种分层不是为了炫技而是为了解决一个根本矛盾大语言模型的上下文窗口context window是一个固定大小的、易失的、不可靠的“临时记忆”而真实业务流程的状态state却是动态增长的、需要持久化的、必须可追溯的“长期记忆”。强行把后者塞进前者就像试图用一张 A4 纸记录一本百科全书的全部内容——纸没破但你永远找不到第 37 卷第 2 章的条目。Harness执行器这是整个架构中最“轻量”也最“无状态”的一层。它本质上就是一个高度优化的、标准化的函数调用器。你向它发送一个execute(name, input)请求它就去调用指定名称的工具比如search_web、write_file、call_api并将工具返回的原始字符串结果原样交还给你。它不保存任何中间状态不缓存任何历史不理解业务逻辑。它的唯一使命就是快、准、稳地完成一次原子操作。你可以把它想象成一个训练有素的快递员——你告诉他“去 3 号仓库取一个标着‘订单数据’的箱子送到 5 号办公室”他就照做不会问箱子里面是什么也不会把箱子留在自己工位上。这种无状态设计带来了两个巨大好处一是极致的可伸缩性Harness 实例可以像 Web 服务器一样水平无限扩展二是极强的容错性任何一个 Harness 崩溃系统只需启动一个新的实例用同一个sessionId调用awake()就能瞬间恢复到崩溃前一刻的执行点因为所有状态都不在它身上。Session会话这是整个架构的“心脏”与“大脑皮层”。它不再是一个存在于模型 prompt 里的、随 token 流动而漂移的模糊概念而是一个被明确定义、独立存储、结构化索引的事件日志Event Log。每一次用户输入、每一次模型推理、每一次工具调用、每一次工具返回、每一次 guardrail 触发、每一次 checkpoint 保存都会被序列化为一条带有时间戳、唯一 ID、类型user_message,model_thought,tool_call,tool_result,guardrail_violation、以及完整 payload 的结构化事件持久化到一个高可用、低延迟的后端存储中很可能是基于分布式 OLAP 数据库或专用时序数据库。这个日志是只追加append-only的不可篡改且天然支持按sessionId、时间范围、事件类型、甚至 payload 内容进行高效查询。这意味着当你的 Agent 在第 42 步出错时你不需要去翻几十页的 debug 日志只需执行一条类似SELECT * FROM session_events WHERE session_id abc123 AND event_type tool_call ORDER BY timestamp DESC LIMIT 10的查询就能精准定位到失败前后的所有交互细节。更重要的是这个日志本身就是 Agent 的“记忆”——模型在每次推理前Harness 会根据当前sessionId从 Session 存储中拉取最近 N 条相关事件比如最近 5 次 tool call 结果、用户最新指令、guardrail 规则变更作为 context 注入模型。这确保了模型永远拥有“刚刚发生过什么”的精确视图而不会因为上下文窗口限制而丢失关键信息。Sandbox沙箱这是整个架构的“免疫系统”与“隔离墙”。它并非一个简单的 Docker 容器而是一个经过深度加固、严格管控的微虚拟机microVM或高度受限的容器运行时。其核心设计原则是“Cattle, not Pets”牛而非宠物每一个 Sandbox 都是短暂的、无状态的、按需创建、用完即焚的。当一个tool_call需要执行外部代码比如运行一段 Python 脚本解析 CSV或访问网络时Harness 会向 Sandbox Manager 发起请求后者会瞬间毫秒级拉起一个全新的、干净的 Sandbox 实例。最关键的安全机制在于凭据Credentials永远不会以环境变量env var或文件形式注入 Sandbox。相反Sandbox Manager 会在 Sandbox 启动时通过一个受控的、单向的 IPC 通道如 Unix Domain Socket将一个短期有效的、作用域精确到本次调用的、带签名的访问令牌access token传递给 Sandbox 内部的工具执行器。这个令牌只能用于本次调用指定的 API 端点且有效期通常只有几分钟。Sandbox 内部的代码永远无法读取到原始的 API Key、OAuth Token 或数据库密码。这从根本上杜绝了历史上无数次发生的惨剧一个 LLM 在生成 curl 命令时因为 prompt 工程失误或上下文混淆把本该隐藏的Authorization: Bearer SECRET直接写进了命令字符串导致密钥被泄露到日志、监控或第三方服务中。Sandbox 的“牛”属性让安全不再是事后补救而是从架构源头就内建的基因。这三层之间的协作流程构成了一个极其健壮的闭环用户发起请求 → Harness 接收并生成sessionId→ Harness 从 Session 存储中加载历史事件 → Harness 将用户输入 历史事件 system prompt 组合成完整 context → Harness 调用 Claude 模型 → 模型返回tool_call指令 → Harness 解析指令 → Harness 向 Sandbox Manager 请求执行 → Sandbox Manager 创建新 Sandbox 并注入临时令牌 → Sandbox 执行工具并返回结果 → Harness 将结果写入 Session Event Log → Harness 再次调用模型……整个过程状态只在 Session 中沉淀执行只在 Harness 中流转风险只在 Sandbox 中隔离。这种分离让每一层都可以独立演进你可以升级 Harness 的调度算法而不影响 Session 存储格式你可以更换 Session 的底层数据库从 PostgreSQL 切换到 ClickHouse而不改变 Harness 的 API你可以为 Sandbox 引入新的硬件级隔离技术如 Intel TDX而不修改 Harness 的任何一行代码。这正是 Anthropic 工程博客中所强调的“稳定抽象stable abstractions”——它不是一句空话而是通过强制的接口契约和清晰的职责划分为未来十年的迭代铺平了道路。2.2 凭据隔离为什么“环境变量”是生产环境的定时炸弹在 Agent 系统中凭据管理Credential Management从来都不是一个“高级功能”而是决定系统生死的“基础安全红线”。我亲身经历过两次因凭据处理不当导致的严重事故一次发生在内部 PoC 阶段另一次则直接导致了客户合同的终止。第一次我们为了快速验证一个财务数据汇总 Agent把一个测试环境的数据库连接字符串包含用户名和密码直接写进了 Agent 的 system prompt 里。模型在生成 SQL 查询时偶尔会把整个 prompt 的一部分包括那串密码当作注释原样输出到日志中。这个日志被自动同步到一个共享的 ELK 集群而集群的访问权限设置过于宽松。三天后安全团队在例行扫描中发现了这条日志立刻叫停了所有相关项目。第二次更致命一个集成 Slack 的客服 Agent需要调用公司内部的 ticketing API。开发同学图省事把 API Token 作为环境变量注入了运行 Agent 的 Kubernetes Pod。某天一位新入职的运维同事在排查一个网络问题时习惯性地执行了kubectl describe pod agent-pod-name这个命令会输出 Pod 的完整 spec其中就包含了所有环境变量。他随手把这个输出截图发到了一个跨部门的技术讨论群里。不到一小时这个 Token 就被爬虫抓取并在暗网论坛上被标价出售。虽然我们迅速轮换了 Token但这次事件暴露了一个残酷现实在复杂的、多角色参与的现代软件交付链中“人”的操作失误是无法完全避免的而将凭据以明文、可读、可复制的形式暴露在任何可能被人类接触的界面上无异于在雷区裸奔。Anthropic Managed Agents 对此给出的方案是彻底摒弃“环境变量”这一在传统 Web 开发中习以为常、但在 Agent 场景下极度危险的模式。它的凭据隔离机制建立在三个相互强化的支柱之上Vault First保险柜优先所有凭据API Keys、OAuth Tokens、Database Credentials都必须首先存入 Anthropic 自建的、符合 FIPS 140-2 加密标准的密钥管理服务KMS中。这个 KMS 是一个独立的、高可用的服务与 Agent Runtime 完全物理隔离。开发者在定义 Agent 的 YAML 配置时不能写api_key: sk-xxx而必须写credential_ref: vault://prod/slack-bot-token。这个credential_ref是一个指向 KMS 中某个密钥的、不可伪造的引用标识符URI它本身不包含任何敏感信息。Just-in-Time (JIT) Provisioning即时供应Sandbox 的生命周期极短通常只有几秒到几分钟。凭据的“激活”也必须与之匹配。当 Harness 决定需要执行一个需要凭据的tool_call时它会向 Sandbox Manager 发送一个包含credential_ref和本次调用所需权限范围scope的请求。Sandbox Manager 收到请求后会立即向 KMS 发起一个“签发短期令牌short-lived token”的调用。KMS 会验证请求者的身份Harness 的服务证书、检查credential_ref的有效性、确认请求的 scope 是否在授权范围内然后生成一个有效期仅为 5 分钟、且绑定到本次特定tool_call的 JWTJSON Web Token。这个 JWT 包含了所有必要的访问权限声明claims但绝不包含原始凭据。Sandbox-Only Delivery沙箱专属投递这个 JWT 不会以任何形式出现在 Sandbox 的文件系统或进程环境里。Sandbox Manager 会通过一个仅在 Sandbox 启动瞬间开放、且只允许单次读取的、基于内存映射memory-mapped file或 Unix Domain Socket 的安全 IPC 通道将 JWT 的二进制内容直接“推送”给 Sandbox 内部一个预置的、最小化的工具执行器tool executor。这个执行器是 Sandbox 镜像的一部分经过严格审计其唯一功能就是接收这个 JWT将其作为Authorizationheader 的值向目标 API 发起 HTTPS 请求。JWT 一旦被读取IPC 通道立即关闭JWT 在 Sandbox 内存中的副本也会被立即清零zeroed out。整个过程中原始凭据从未离开 KMSJWT 从未以明文形式存在于任何可被ps或env命令读取的上下文中Sandbox 内部的任何其他代码包括可能被模型生成的恶意代码都无法访问到这个 JWT。这套机制的效果是颠覆性的。它让“凭据泄露”这个威胁模型从一个高概率、高影响的“必然风险”降级为一个极低概率、极低影响的“理论风险”。即使一个 Sandbox 被攻破攻击者最多只能拿到一个 5 分钟后就自动失效的 JWT且这个 JWT 只能用于本次调用指定的 API 端点。他无法用它去访问数据库无法用它去调用其他服务更无法用它去获取其他凭据。这不再是“如果被黑了怎么办”的被动防御而是“让黑客根本找不到钥匙孔”的主动免疫。对于 Rakuten 这样的大型电商集团其销售、营销、财务 Agent 需要同时对接数十个 SaaS 服务Salesforce、HubSpot、QuickBooks、Shopify每个服务都有不同的 API 访问策略和安全要求。Managed Agents 的凭据隔离让他们无需为每个 Agent 单独设计、实现、审计和维护一套复杂的凭据轮换与分发机制而是将这项高风险、高专业度的工作完全托付给 Anthropic 的专业安全团队。这节省的不仅是开发时间更是每年数百万美元的潜在安全事件响应成本和声誉损失。3. 实操指南从零部署一个生产级 Claude Agent3.1 环境准备与账号开通避开第一个深坑在你敲下第一行curl命令之前有三个看似琐碎、实则决定成败的前置步骤我建议你用至少 30 分钟一丝不苟地完成。很多团队在兴奋地尝试 Managed Agents 时往往跳过这一步结果卡在第一步长达数小时甚至误以为是服务故障。这不是危言耸听而是我在三家不同客户的现场亲眼见证过的高频问题。第一步确认你的 Anthropic 账号已启用 Managed Agents Beta 权限。这是最容易被忽略的一环。Anthropic 并未对所有付费账号自动开放 Managed Agents。你需要登录 Anthropic Console 进入Account Settings API Access页面。在这里你会看到一个名为Managed Agents (Beta)的开关。请务必确认它处于ON状态。如果你看到的是灰色的Request Access按钮点击它填写一份简短的申请表主要询问你的使用场景和预计规模通常会在 24 小时内收到批准邮件。切记这个开关是按账号account控制的而不是按 API Key 控制的。即使你有多个有效的 API Key只要账号权限没开所有 Key 都会返回403 Forbidden。我曾见过一位资深工程师在凌晨三点反复测试curl -X POST https://api.anthropic.com/v1/agents始终得到 403最后发现只是因为他的个人账号还在等待审批而团队的主账号早已开通。解决方案很简单用团队主账号的 API Key 来操作或者耐心等待审批。第二步为你的 Agent 创建一个专用的、最小权限的 API Key。绝对不要使用你在本地开发时一直用的那个“万能 Key”。Managed Agents 的调用会产生两种费用一是标准的 Claude token 费用按输入/输出 token 计费二是新增的Session Hour费用$0.08/小时。这个 Session Hour 费用是按 API Key 的调用行为来计费的。如果你把一个拥有全权限的 Key 泄露出去攻击者可以用它来疯狂创建和运行 Agent让你的账单在一夜之间飙升到数万美元。因此强烈建议你进入API Keys页面点击Create New Key在弹出的对话框中取消勾选所有权限All Permissions然后手动勾选仅需的两项Manage Agents和Invoke Agents。为这个 Key 命名例如prod-sales-agent-key并将其安全地存储在你的团队密码管理器如 1Password 或 Bitwarden中。这个 Key 将只用于生产环境的 Agent 调用与你的开发、测试 Key 完全隔离。这是一个基本的安全最佳实践其重要性不亚于为数据库设置强密码。第三步在你的本地开发环境中安装并配置anthropicPython SDK。Anthropic 官方 SDK 是目前最稳定、文档最全的客户端。请确保你使用的是v0.35.0 或更高版本因为旧版本不支持 Managed Agents 的新 API。打开你的终端执行pip install --upgrade anthropic安装完成后创建一个.env文件将你的新 API Key 写入其中ANTHROPIC_API_KEYsk-ant-api03-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx然后在你的 Python 脚本中使用os.getenv(ANTHROPIC_API_KEY)来加载它。切记永远不要在代码中硬编码 API Key我们曾经在一个 GitHub 仓库的config.py文件里不小心提交了一个测试 Key虽然很快删除但还是被一个自动化爬虫抓取并在 12 小时内被用于发送数千封垃圾邮件。这个教训让我们所有项目都强制启用了.gitignore对所有*.env和*config*.py文件的全局忽略。完成这三个步骤后你的环境才算真正准备好。接下来我们就可以开始构建 Agent 了。记住这三步不是“准备工作”而是生产环境的基石。跳过它们后面所有的优雅架构、精妙逻辑都可能因为一个 403 错误或一次意外的账单爆炸而付诸东流。3.2 Agent 定义用 YAML 描述你的业务意图Managed Agents 的核心哲学是“让开发者描述‘做什么’而不是‘怎么做’”。这体现在其 Agent 定义方式上——你不再需要写数百行 Python 代码来初始化 LangChain 的AgentExecutor、配置Tool、设置Memory、编写OutputParser。你只需要用一份结构清晰、语义明确的 YAML 文件告诉 Anthropic 你的 Agent 是谁、能干什么、有什么规矩。这份 YAML 就是你的 Agent 的“宪法”它定义了其存在的全部意义。下面是一个为 Notion 团队设计的、用于“自动整理会议纪要并同步到 CRM”的生产级 Agent 的完整 YAML 示例。我会逐行解释其背后的工程考量# agent.yaml name: notion-crm-sync-agent description: An agent that extracts action items and decisions from meeting transcripts stored in Notion pages, and creates corresponding tasks and contacts in Salesforce CRM. # 1. System Prompt: 这是 Agent 的“灵魂”和“职业操守” system_prompt: | You are a meticulous and reliable operations assistant for a sales team. Your primary goal is to process meeting transcripts from Notion and ensure all actionable outcomes are captured in Salesforce. - Always extract EXACTLY the speakers name, the action item, the deadline (if mentioned), and the owner (if assigned). - If a deadline is vague (e.g., ASAP, soon), set it to 3 business days from today. - If no owner is assigned, assign it to the meeting organizer. - NEVER invent or hallucinate details. If information is missing, leave the field blank and note MISSING in your reasoning. - Your output MUST be a valid JSON array of objects, each with keys: speaker, action_item, deadline, owner, notes. # 2. Tools: 这是 Agent 的“手脚”定义了它能调用的外部能力 tools: - name: notion_search_pages description: Searches Notion database for pages matching a query. Returns page IDs and titles. input_schema: type: object properties: query: type: string description: The search term, e.g., Q2 Sales Review Meeting database_id: type: string description: The Notion database ID where meetings are stored - name: notion_read_page description: Reads the full content of a Notion page by its ID. Returns plain text transcript. input_schema: type: object properties: page_id: type: string description: The Notion page ID to read - name: salesforce_create_task description: Creates a new task in Salesforce. Returns the created task ID. input_schema: type: object properties: subject: type: string description: The task subject, e.g., Follow up on pricing proposal what_id: type: string description: The Salesforce ID of the Account or Opportunity this task relates to owner_id: type: string description: The Salesforce ID of the user who owns this task activity_date: type: string description: The due date in YYYY-MM-DD format description: type: string description: The full action item description - name: salesforce_find_contact description: Finds a contact in Salesforce by name and email. Returns contact ID if found, else null. input_schema: type: object properties: first_name: type: string last_name: type: string email: type: string # 3. Guardrails: 这是 Agent 的“法律”和“道德底线”防止它越界 guardrails: # 禁止访问任何与 Notion/Salesforce 无关的外部网站 - type: block_url pattern: ^(?!https?://(notion\.so|salesforce\.com)).*$ message: Access to external websites is strictly prohibited. Only Notion and Salesforce domains are allowed. # 禁止生成任何包含信用卡号、SSN、密码等 PII 的文本 - type: pii_detection categories: [CREDIT_CARD, US_SSN, PASSWORD] action: block message: PII detection triggered. This action is blocked for security compliance. # 限制单次会话中调用同一工具的最大次数防止单点故障导致无限循环 - type: max_tool_calls_per_session tool_name: notion_search_pages limit: 3 message: Maximum number of searches per session exceeded. Please refine your query. # 4. Credentials: 这是 Agent 的“通行证”指向 Vault 中的安全凭据 credentials: notion_api_key: vault_ref: vault://prod/notion-integration-key salesforce_access_token: vault_ref: vault://prod/salesforce-oauth-token这份 YAML 的精妙之处在于它将复杂的工程决策转化为了简洁的声明式配置system_prompt不再是随意拼凑的几句话而是一份经过产品、法务、安全多方评审的、具有法律效力的“行为准则”。它用明确的、可执行的指令“EXACTLY”, “NEVER”, “MUST”替代了模糊的期望“be helpful”, “do your best”这直接决定了模型输出的结构化程度和可靠性。我们曾将system_prompt中的 “leave the field blank” 改为 “use N/A”结果导致下游 Salesforce API 因字段类型不匹配而批量失败。一个词的差异就是生产事故的导火索。tools的input_schema是一个强大的契约。它强制要求每个工具的输入参数都必须是类型安全、结构清晰的 JSON Schema。这不仅让 Anthropic 的 Harness 能够在调用前进行严格的参数校验避免传入一个字符串却期望一个对象更重要的是它为未来的自动化测试提供了基础。你可以轻松地为notion_search_pages编写单元测试模拟各种query和database_id输入验证 Harness 是否能正确解析并转发。这种可测试性是传统基于字符串拼接的tool_call方式永远无法企及的。guardrails是真正的“安全护栏”而非装饰品。block_url规则利用了正则表达式的否定前瞻negative lookahead精确地只允许 Notion 和 Salesforce 的域名连notion.so的子域名如myworkspace.notion.so和salesforce.com的子域名如na123.salesforce.com都自动包含在内而将所有其他流量一概拦截。pii_detection则直接集成了行业标准的 PII 识别引擎其检测精度远超任何自研的关键词黑名单。max_tool_calls_per_session是一个典型的“熔断器circuit breaker”设计它承认了在复杂 Agent 流程中单点工具故障如 Notion API 临时返回 503可能导致 Agent 陷入无限重试的死循环。这个限制确保了会话的最终可终止性。credentials部分再次印证了前面提到的 Vault First 原则。vault_ref的 URI 格式清晰地表明了凭据的来源和生命周期管理责任归属——它不在你的代码里不在你的配置里而在 Anthropic 的专业 KMS 里。你只需关心“用哪个”而无需操心“怎么管”。当你将这份 YAML 通过anthropicSDK 提交后Anthropic 的后台会对其进行静态分析验证 YAML 语法、检查input_schema的合法性、校验vault_ref的存在性、评估guardrails的冲突性。只有当所有检查都通过这个 Agent 才会被创建并分配一个唯一的agent_id。这个过程就是将你的业务意图从一份文档转化为一个可运行、可审计、可管理的生产资产的第一步。3.3 创建、调用与监控一个完整的会话生命周期现在你的 Agent 已经在 Anthropic 的云端“注册”完毕拥有了自己的agent_id。接下来我们将演示如何在生产环境中安全、可靠、可观测地运行它。整个过程分为三个阶段创建会话Create Session、驱动会话Drive Session和监控与审计Monitor Audit。每一个阶段都对应着 Managed Agents 架构中一个核心组件的职责。阶段一创建会话Create Session这是会话的“出生证明”。你向 Anthropic 的 API 发送一个POST /v1/agents/{agent_id}/sessions请求附带一个简单的 JSON body{ name: Q2-Sales-Review-2026-04-15, metadata: { source: notion-webhook, meeting_id: page_abc123 } }name是一个便于人类识别的会话名称metadata是一个任意的键值对字典用于存储与业务相关的上下文信息如触发该会话的 Notion 页面 ID、Slack Channel ID 等。API 成功响应后你会得到一个包含session_id、created_at、statusactive等字段的 JSON。这个session_id就是你后续所有操作的“身份证”。关键经验请务必立即将这个session_id记录到你的业务系统中例如作为一条新记录插入到你的内部审计数据库。不要依赖内存或临时变量。因为会话的生命周期可能长达数小时而你的应用服务器可能会重启。丢失session_id就意味着你失去了对这个会话的所有控制权只能任由它在云端默默运行或超时结束。阶段二驱动会话Drive Session这是会话的“心跳”。你通过POST /v1/sessions/{session_id}/messages向会话发送用户消息User Message并接收模型的响应Model Response。这是一个典型的 request-response 循环# 发送用户消息启动一个新会话 curl -X POST https://api.anthropic.com/v1/sessions/$SESSION_ID/messages \ -H x-api-key: $ANTHROPIC_API_KEY \ -H Content-Type: application/json \ -d { role: user, content: Please process the meeting transcript from Notion page Q2 Sales Review Meeting and sync all action items to Salesforce. }API 的响应会是一个包含message_id、roleassistant、content模型的 JSON 输出、tool_use如果模型决定调用工具则包含name和input等字段的 JSON。如果响应中包含了tool_use你的应用逻辑就需要接管去执行相应的业务代码例如调用 Notion API 获取页面内容然后将结果通过POST /v1/sessions/{session_id}/tool_results发送回去# 发送工具执行结果 curl -X POST https://api.anthropic.com/v1/sessions/$SESSION_ID/tool_results \ -H x-api-key: $ANTHROPIC_API_KEY \ -H Content-Type: application/json \ -d { tool_use_id: toolu_abc123, content: [{\speaker\: \Alex Chen\, \action_item\: \Send revised pricing proposal to Acme Corp\, \deadline\: \2026-04-22\, \owner\: \Alex Chen\, \notes\: \\}] }Harness 会自动接收这个结果并将其作为一条tool_result事件写入 Session Event Log然后再次调用 Claude 模型开始下一个推理循环。关键经验这个循环的“驱动者”必须是你的应用而不是 Anthropic。Managed Agents 不会主动轮询你的服务它是一个被动的、事件驱动的系统。你的应用需要负责整个流程的 orchestration编排包括何时发送用户消息、如何解析tool_use、如何执行业务逻辑、如何处理工具调用失败是重试、降级还是直接终止会话、以及何时认为会话已完成例如模型返回了{status: completed}。这听起来增加了复杂性但恰恰是它强大之处——你保留了对业务流程的完全控制权而将最易出错的状态管理和工具调用封装了起来。阶段三监控与审计Monitor Audit这是会话的“健康档案”。Managed Agents 提供了两个核心的监控入口实时状态查询你可以随时调用GET /v1/sessions/{session_id}来获取会话的当前状态active,completed,failed,expired、最后活动时间、已消耗的 token 数、已运行的 session hour 数等。这对于实现超时自动清理、资源配额告警等运维功能至关重要。事件日志查询Event Log Query这是 Managed Agents 最具革命性的功能。你可以调用GET /v1/sessions/{session_id}/events并传入limit、before、after等参数来检索该会话产生的所有结构化事件。例如要查看该会话中所有失败的工具调用