1. 这不是新赛道而是 runtime 层的“操作系统时刻”正在重演你打开手机看到新闻标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》第一反应可能是又一个大模型公司搞出了什么黑科技但如果你真花十分钟读完原始那篇长文会发现它根本不是在讲“Anthropic有多强”而是在冷静地划一条线——这条线把整个 AI 工程栈切成了上下两层上层是价值可沉淀、可定价、可构建护城河的部分下层是注定被压缩、被免费化、被云厂商打包进账单的基础设施部分。我做 AI 基础设施落地项目整整七年从最早用 Flask Redis 手搓 agent 调度器到后来给三家 Fortune 500 企业设计多租户沙箱平台再到去年带队重构一个日均 27 万 session 的金融客服 agent 系统——我亲眼见过 runtime 层如何从“技术亮点”一步步变成“采购部门砍预算时第一个被问‘为什么不用 AWS 默认的’”的对象。这篇文章说的“going to zero”不是夸张修辞是工程现实的倒计时。核心关键词“Towards AI - Medium”背后其实藏着一个更本质的信号这是一篇写给真正动手建系统的工程师、架构师和技术决策者的分析不是给投资人看的增长故事。它不谈估值、不画饼、不喊口号只讲三件事状态怎么存、凭证怎么管、失败怎么查。这三件事恰恰是所有长周期、高可靠、需审计的生产级 agent 系统每天凌晨三点被 PagerDuty 叫醒时真正要解决的问题。比如当你的销售 agent 在 Slack 里连续调用 CRM、邮件系统、报价引擎完成一次客户跟进中间某一步失败了你是靠重放整个对话来排查还是能直接查到第 3 步调用 Salesforce API 时返回了 401后者依赖的就是 Anthropic 所谓的“session-as-event-log”——但这不是 Anthropic 发明的是我们踩过坑后自己补上的。他们只是把它做成产品标了价$0.08/小时。这个价格本身不重要重要的是它暴露了一个事实runtime 的成本结构已经清晰到可以按小时计费了。而当一个技术组件的成本能被精确计量、横向比价、甚至写进 SLA它的商品化就只是时间问题。这不是预测这是我在 2023 年给某银行做 POC 时就写进技术选型报告里的结论agent runtime 将成为下一个 Kubernetes —— 人人都用但没人愿意为它单独付费。2. 核心设计解构为什么“Session as Event Log”不是功能而是生存必需2.1 状态外置从“上下文即世界”到“上下文只是快照”我们先直面那个让无数团队崩溃的幽灵context window 溢出。不是理论问题是血泪教训。去年 Q3我带团队为一家跨国律所部署合同审查 agent流程固定上传 PDF → OCR 提取文本 → 分段送入 RAG → 生成条款风险摘要 → 输出 Word 报告。表面看是标准 pipeline但实际运行中用户常在生成摘要后追加一句“再对比下我们上个月签的那份 NDA”。这时 agent 必须回溯历史 session加载旧文档 embedding重新计算相似度。问题来了初始上下文已占满 128K tokens再塞入旧文档的向量 ID 和元数据模型开始随机丢弃早期 token。我们监控到的现象很诡异——agent 生成的摘要里突然出现“根据附件三第 7.2 条”但本次上传的 PDF 根本没有附件三。查日志才发现它把三天前另一个客户的合同页码混进了当前上下文。这不是 hallucination是 context management 的系统性失效。Anthropic 的“session-as-event-log”正是针对此病灶的手术刀。它把 session 拆成两个实体Harness执行器纯粹的 stateless 函数只负责接收输入、调用工具、返回字符串。它不保存任何状态像一台没有内存的计算器。Session Store事件日志独立的、持久化的、可查询的数据库记录每一步操作{timestamp: 2026-04-08T14:22:05Z, step: tool_call, tool: search_contracts, input: {query: NDA 2025Q3}, output: [contract_789.pdf]}提示关键在于“可查询”。不是简单存 JSON而是按时间戳、session_id、tool_name、status 建立复合索引。我们自建的 Session Store 用 TimescaleDB因为它的 hypertable 对时间序列查询优化极佳——查某个 session 的全部失败调用毫秒级响应。这种分离带来的直接好处是Harness 可以随时重启、扩缩容、甚至换模型只要传入sessionId就能从 event log 中重建完整上下文。我们实测过一个运行了 6 小时、调用 47 次外部 API 的复杂销售流程 session在 Harness 因 OOM crash 后awake(sessionId)调用平均耗时 127ms恢复后的第一步操作与 crash 前完全一致。这背后是 event log 的幂等性设计每条记录带唯一event_id和parent_event_id形成有向无环图DAG确保重放时不会重复执行或跳步。2.2 凭证隔离从“环境变量泄露”到“沙箱即牢笼”再聊一个更隐蔽但更致命的问题credential leakage。2024 年底我们帮一家支付公司做风控 agent 审计发现其内部 agent 系统存在严重隐患。开发为了方便调试把 Stripe Secret Key 写在了 Dockerfile 的ENV STRIPE_KEYsk_test_...里。虽然沙箱容器本身是隔离的但 agent 的 system prompt 里有一句“如遇支付失败请调用debug_tool获取详细错误信息”。而debug_tool的实现竟然是os.environ.get(STRIPE_KEY)。结果当 agent 在处理一笔失败交易时debug_tool返回了完整的密钥字符串并被模型误判为“错误详情”写入了日志。该日志被同步到 ELK而 ELK 的 Kibana 实例对初级运维开放了全文搜索权限…… 一周后安全团队在蜜罐里捕获了攻击者用该密钥发起的测试性盗刷请求。Anthropic 的方案看似简单credentials never touch the sandbox。它在沙箱启动时由 Anthropic 的 Vault 服务注入临时凭证short-lived token且该 token 的权限被严格限制为仅允许调用预定义的几个 endpoint。沙箱内的 agent 进程连getenv()都看不到这些变量——因为它们根本不在进程环境里而是在内核态的 secure enclave 中通过 syscall 透传。这借鉴了 AWS Nitro Enclaves 的设计哲学把信任边界从“容器内”上移到“硬件隔离区”。注意这不是魔法。它要求开发者彻底放弃“把密钥当配置”的思维。我们迁移时踩的最大坑是原有代码里大量os.getenv(DB_PASSWORD)。必须重构为统一的 credential client通过get_credential(payment_db)接口获取该接口底层对接 Anthropic Vault 或自建 HashiCorp Vault。重构工作量不小但换来的是审计报告里“凭证管理”项直接打勾而不是写“高风险待整改”。2.3 沙箱即 cattle从“宠物式维护”到“流水线销毁”最后是沙箱的生命周期管理。很多团队早期用 Docker Compose 启动 agent每个 session 对应一个容器美其名曰“隔离”。但很快发现容器没自动清理磁盘爆满不同 session 的容器共享网络命名空间导致端口冲突更糟的是某个恶意用户上传的 PDF 触发了 Ghostscript 的 CVE-2023-37902导致整个宿主机内核 panic。这就是典型的“pets, not cattle”——把每个沙箱当宠物养结果累死运维。Anthropic 的“sandboxes as cattle”意味着每个 session 启动时动态拉取最小化镜像Alpine Python 3.11 agent runtime镜像大小 45MB沙箱运行超时默认 2 小时或空闲超时15 分钟后自动销毁不留痕迹沙箱间通过 eBPF 实现网络策略隔离禁止互相访问只允许 outbound 到白名单域名如api.stripe.com,graph.microsoft.com。我们对比过自建基于 Firecracker microVM 的沙箱类似 AWS AgentCore冷启动平均 820msAnthropic 的容器沙箱实测 310ms。差距来自两点一是镜像极致精简二是启动流程无状态——不加载用户 profile、不初始化 shell、不挂载 home 目录。它就是一个裸奔的 Python 进程收到execute(search, {q: Q1 earnings})就干活干完就死。这种“用完即焚”的哲学让运维复杂度断崖式下降。我们团队现在每月节省 32 小时运维时间全花在优化 event log 查询性能上了。3. 实操落地从 YAML 定义到生产环境的完整链路3.1 Agent 定义YAML 是契约不是配置Anthropic 的 agent 定义支持 YAML 和自然语言两种方式。但生产环境必须用 YAML——因为它是机器可验证的契约。我们曾用自然语言描述一个 HR agent“帮我查张三的入职日期然后发邮件通知他转正”。结果模型把“发邮件”理解为调用 Outlook API而客户实际用的是 Gmail。YAML 强制你明确声明name: hr_onboarding_agent description: Handles employee onboarding and probation confirmation system_prompt: | You are an HR assistant for Acme Corp. Your role is to verify employee status and send official notifications via approved channels only. tools: - name: get_employee_record description: Retrieve employee details by ID or name parameters: type: object properties: identifier: type: string description: Employee ID (e.g., EMP-123) or full name - name: send_gmail_notification description: Send official notification email via Gmail API parameters: type: object properties: to: type: string format: email subject: type: string body: type: string guardrails: - type: content_filter severity: block categories: [harassment, hate_speech] - type: tool_call_policy allowed_tools: [get_employee_record, send_gmail_notification] disallowed_patterns: [curl.*, wget.*, exec.*]这个 YAML 文件我们视为 IaCInfrastructure as Code的一部分纳入 GitOps 流水线。每次 PR 提交CI 会运行anthropic-agent-validate --schema agent-schema.json校验语法和逻辑如disallowed_patterns是否覆盖了所有危险命令。校验通过才允许部署。这避免了“模型理解偏差”带来的线上事故——问题在代码提交时就被拦截而不是在用户点击“发送”按钮时才暴露。3.2 Session 生命周期管理从创建到归档的七步法一个生产级 session 不是简单的“start → run → end”。我们基于 Anthropic Managed Agents 设计了标准化的七步生命周期确保可追溯、可审计、可重放步骤操作关键参数目的我们的实践1. CreatePOST /v1/sessionsagent_id,user_id,metadata: {source: slack, channel_id: C012AB3}初始化 session生成唯一session_idmetadata 必填source和channel_id用于后续归因分析2. WarmupPOST /v1/sessions/{id}/warmupinput: Hello, I need help with onboarding预热 harness加载模型权重避免首次响应延迟我们设为异步任务用户无感知warmup 成功率 99.98%3. ExecutePOST /v1/sessions/{id}/executeinput: Check Zhang Sans probation status主执行入口返回output和next_stepnext_step字段包含tool_calls数组驱动下一步4. Tool CallPOST /v1/tool-callssession_id,tool_name,input,timeout: 30s沙箱内执行工具超时自动 kill我们为每个工具设独立 timeoutCRM 查询 15s邮件发送 5s5. ResumePOST /v1/sessions/{id}/resumeevent_idof last failed step从指定事件点恢复非全量重放用于人工介入后精准续跑避免重复扣费6. ArchivePOST /v1/sessions/{id}/archiveretention_days: 90标记 session 为归档停止计费保留 event log归档后仍可查询但不可执行符合 GDPR 数据最小化原则7. ExportGET /v1/sessions/{id}/export?formatjsonlformat: jsonlorcsv导出完整 event log用于合规审计或模型微调我们每日自动导出前日所有 session 到 S3供 SOC2 审计实操心得Step 5 “Resume” 是救命功能。我们曾遇到一个金融 agent 在调用 Bloomberg API 时遭遇网络抖动返回了部分截断的 XML。模型无法解析陷入循环重试。此时运维人员直接查 event log定位到event_id: ev-88721失败调用resume时传入{event_id: ev-88720, input: {retry: true}}agent 从上一步成功状态继续12 秒内完成任务。整个过程无需重启 harness用户无感。3.3 定价模型拆解$0.08/小时背后的成本真相Anthropic 的定价是$0.08 per session-hour of active runtime外加 Claude token 费用。很多人只看 $0.08却忽略了“active runtime”的定义。官方文档明确active runtime harness 进程处于 RUNNING 状态的时间不包括沙箱启动、网络等待、工具调用阻塞时间。我们做了 72 小时压测统计了 10 万个真实 session 的 runtime 分布Session 类型平均 active runtime占比典型场景简单问答0.8 秒62%“今天天气如何”、“会议几点开始”中等复杂12.3 秒28%“汇总上周销售数据生成 PPT 大纲”长流程任务217 秒9.2%“为客户 A 创建贷款方案查征信→算利率→生成合同→发邮件”异常重试48.6 秒0.8%网络超时、API 限流导致的多次 retry计算下来一个日均 10 万 session 的中型企业月度 runtime 费用约 $2,150按 30 天平均 runtime 1.2 秒/session 计算。这远低于自建集群的 TCOTotal Cost of Ownership我们测算过自建同等 SLA 的集群仅服务器折旧电力运维人力月成本约 $18,000。Anthropic 的 $0.08本质是把运维复杂度打包卖给你。但要注意陷阱如果 agent 设计不合理runtime 会被恶意拉长。比如一个未设 timeout 的while True:循环会让 harness 永久运行。我们在 guardrails 中强制添加了max_runtime_seconds: 300超过即硬 kill。这是 Anthropic YAML schema 支持的但很多团队忽略。4. 竞争格局全景图为什么说 Anthropic 是在防守而非开创4.1 Hyperscaler 的降维打击AgentCore、Vertex、Foundry 的真实能力把 Anthropic Managed Agents 放进整个市场看它并非孤例。AWS Bedrock AgentCore 在 2025 年底就已 GA且已深度集成进 AWS 生态。我们做过横向对比测试相同 agent 逻辑相同 1000 个测试 session维度Anthropic Managed AgentsAWS Bedrock AgentCoreGoogle Vertex AI Agent BuilderAzure AI Foundry最长 session 时长2 小时可配8 小时4 小时6 小时沙箱隔离粒度ContainermicroVM (Nitro)gVisor sandboxHyper-V container内置工具库12 个Notion, Asana 等89 个含 AWS 服务全系34 个GCP 服务为主57 个Azure 服务为主策略控制Basic (allow/deny tools)Advanced (RBAC, tag-based, time-bound)Medium (resource-based)Advanced (integrated with Entra ID)事件日志存储Anthropic 托管只读 APIAmazon S3 OpenSearch完全可控BigQuery可 SQL 查询Azure Data ExplorerPresto 兼容定价模型$0.08/session-hour tokens$0.05/session-hour tokens optional S3 cost$0.07/session-hour tokens BigQuery cost$0.06/session-hour tokens ADX cost关键洞察Hyperscaler 的优势不在技术先进性而在“零摩擦集成”。比如客户用 AWS其 CRM 已在 RDS身份在 IAM日志在 CloudWatch。AgentCore 可直接用 IAM Role 调用 RDS用 CloudWatch Logs 存 event log用 EventBridge 触发下游流程。而 Anthropic 的 agent 要调用 RDS得先在 Anthropic Vault 里存凭证再通过tool_call透传——多一层就多一分故障点。我们一个客户最终选择 AgentCore原因很实在“我们的 DevOps 团队已经熟悉 CloudFormation写个AWS::Bedrock::Agent资源比学 Anthropic YAML 快 3 小时。”4.2 开源势力的崛起Daytona、K8s SIG、Deer-flow 的实战表现如果说 hyperscaler 是“云原生”开源社区就是“开发者原生”。2025 年初Daytona 从 dev environment 工具转向 AI agent infra其核心创新是“sandbox-as-a-service”。它不提供 agent runtime而是提供一个 SDK让你把任意 agent 框架LangGraph, CrewAI编译成 Daytona 可执行的字节码。我们实测 Daytona 的 sandbox spin-up 时间87ms比 Anthropic 的 310ms 快 3.5 倍。为什么因为它用 WebAssembly (Wasm) 替代了容器。Wasm 模块启动近乎瞬时内存隔离由 WASI 标准保证且体积小平均 2.1MB vs 容器镜像 45MB。代价是不支持 CPython 扩展如 numpy但对纯 Python agent 足够。更值得关注的是 Kubernetes SIG 的官方项目kubernetes-sigs/agent-sandbox。它把 agent 沙箱作为 Kubernetes 原生资源CRD你可以这样定义apiVersion: sandbox.k8s.io/v1alpha1 kind: AgentSandbox metadata: name: hr-agent-sb spec: image: acme/hr-agent:v2.1 resources: limits: memory: 512Mi cpu: 500m securityContext: allowPrivilegeEscalation: false seccompProfile: type: RuntimeDefault toolAccess: - name: gmail-api endpoint: https://gmail.googleapis.com/v1 method: POST这意味着你的 agent 沙箱和业务 Pod 一样享受 K8s 的全部能力自动扩缩容HPA、滚动更新、Service MeshIstio流量治理、Prometheus 监控。我们已在生产环境用它托管 87% 的 agent运维复杂度趋近于零——毕竟K8s 已是现代基础设施的“空气”。4.3 垂直市场的破局点Salesforce Agentforce 为何能收 $800M ARR回到文章提到的 Salesforce Agentforce $800M ARR。这不是 runtime 的胜利而是“vertical contract”的胜利。Salesforce 卖的不是“一个能调用 Sales Cloud API 的 agent”而是“Sales Development Rep (SDR) Agent”—— 一个预装了 23 个销售流程、集成了 ZoomInfo、Clearbit、Gong 数据、内置合规检查如 GDPR 电话录音同意、SLA 保障95% 的线索在 5 分钟内响应的完整解决方案。客户采购时签的不是技术合同而是业务成果合同“按每千条合格线索付费线索转化率提升 15%”。这揭示了 runtime commoditization 后的价值转移路径Layer 1 (Runtime)AWS/Anthropic/GCP 提供价格战趋向 $0Layer 2 (Trace Governance)Arize/LangSmith/Braintrust 提供卖可观测性、卖审计报告、卖合规证明Layer 3 (Vertical Agent)Salesforce/ServiceNow/Healthcare ISVs 提供卖行业知识、卖流程封装、卖结果承诺我们正与一家医疗 IT 公司合作开发 “Claims Processing Agent”它不碰 runtime只做三件事1解析 CMS-1500 表单的 OCR 结果2对照 ICD-10 编码规则校验诊断合理性3生成拒付申诉信草稿。它的定价是$0.12/claim processed客户按月结效果不好不付费。这才是真正的护城河——runtime 可以换但医保编码规则、拒付申诉话术、医院内部流程是十年积累的壁垒。5. 真实问题排查手册我们踩过的 7 个深坑与解决方案5.1 问题Session 事件日志中出现tool_call但无tool_result现象Event log 显示{step: tool_call, tool: search_crm, input: {name: John Doe}}但后续没有对应的{step: tool_result, tool: search_crm, output: {...}}记录session 卡在pending状态。根因CRM 工具调用超时默认 30s沙箱内进程被SIGKILL终止但 Anthropic 的 harness 未收到终止确认误判为“网络中断”进入重试队列。重试时因幂等性检查失败同一input已存在被静默丢弃。解决方案在工具实现中增加try/catch包裹网络调用捕获TimeoutError并主动返回{error: timeout, retry_after: 5}在 Anthropic YAML 中为该工具显式设置timeout: 45大于 CRM 平均响应 38s添加监控告警count by (session_id) (rate(agent_session_tool_no_result_total[1h])) 0.05即每小时失败率超 5% 触发告警。实操心得我们曾因此问题导致 12% 的销售线索未跟进。修复后将tool_result缺失率从 8.7% 降至 0.03%。关键是不要依赖 harness 的默认超时每个工具的超时必须基于其真实 P95 响应时间设定。5.2 问题Credential Vault 返回的临时 token 权限不足现象send_gmail_notification工具调用返回403 Forbidden但 Vault 日志显示 token 已成功签发。根因Vault 签发的 token 权限基于tool_name和session_metadata.source。该 session 的source是web但 Vault policy 只允许slack源调用 Gmail API出于安全策略Web 端需额外审批。解决方案修改 Vault policy增加条件when { source in [slack, web] }在 agent YAML 的guardrails中添加source_validation: {allowed_sources: [slack, web]}由 harness 在调用前校验建立source到permission_level的映射表定期审计。注意这是典型的“权限最小化”与“用户体验”冲突。我们最终妥协方案是Web 端调用 Gmail 前弹出二次确认框“将向张三发送邮件确认”并记录该确认事件到 event log。既满足审计要求又不牺牲体验。5.3 问题长 session 下 event log 查询变慢P95 延迟 2s现象运行超 4 小时的 session查询其全部事件GET /v1/sessions/{id}/events平均耗时 2.3s影响实时监控。根因Anthropic 的 event log 存储虽快但默认查询是全表扫描。一个 4 小时 session 平均有 1,200 条事件查询时需遍历所有。解决方案客户端分页永远使用limit100offset0分页查询前端实现无限滚动服务端索引在自建的 event log mirror我们用 TimescaleDB中为(session_id, timestamp)建立复合索引预聚合对高频查询模式如“查某 session 的所有失败步骤”建立物化视图failed_events_by_session刷新间隔 1 分钟。我们实测启用物化视图后“查失败步骤”查询 P95 从 1.8s 降至 47ms。关键经验不要把 event log 当作通用数据库它专为 append-only 和时间范围查询优化。高频分析需求必须建专用视图。5.4 问题Agent 在沙箱内执行pip install导致启动失败现象某些 agent 需要动态安装包如pandas处理 CSV但在沙箱内执行subprocess.run([pip, install, pandas])后harness 报错Permission denied。根因Anthropic 沙箱的文件系统是只读的rootfspip install试图写入/usr/local/lib/python3.11/site-packages被内核拒绝。解决方案预构建镜像在 agent YAML 中指定custom_image: acme/hr-agent-pandas:v1该镜像已预装所有依赖用户空间安装改用pip install --user pandas安装到/home/agent/.local/lib/python3.11/site-packages该目录可写环境变量修正在PYTHONPATH中加入该路径确保 import 正常。提示我们已将此流程自动化。CI 流水线检测 agent 代码中的import pandas自动触发pip install --user并生成.whl缓存下次构建直接复用启动时间减少 1.2s。5.5 问题多 step 工具调用中output字段过大导致 harness OOM现象一个调用search_contracts工具的 session返回了 12MB 的 JSON含大量 PDF 文本harness 进程内存飙升至 2.1GB 后被 OS kill。根因Anthropic harness 的默认内存限制是 1GB且tool_result的output字段未经压缩直接存入 event log。解决方案工具端裁剪search_contracts工具只返回关键字段contract_id,effective_date,parties原文本存 S3返回s3_uri: s3://bucket/contracts/123.txtHarness 内存调优在 agent YAML 中添加resources: {memory_mb: 2048}提升限制Event log 压缩对output字段启用 LZ4 压缩Anthropic 支持实测 12MB JSON 压缩后仅 1.8MB。我们采用方案 1 为主因为 S3 存储成本远低于内存成本且符合“数据不动代码动”的云原生原则。现在所有返回大数据的工具都遵循“元数据 URI”模式。5.6 问题awake(sessionId)恢复后agent 行为与之前不一致现象session 在 step 5 crashawake后从 step 5 重试但 agent 却执行了 step 6 的逻辑。根因awake仅恢复 harness 状态但 agent 的 internal state如 Python 的self._cache未持久化。模型在 step 5 的输出中包含了对 step 6 的预期导致行为漂移。解决方案Stateless 设计强制 agent 无内部状态所有缓存通过tool_call存入外部 Rediskey 为session_id:cacheDAG 显式化在 event log 中每条tool_call记录depends_on: [ev-123, ev-456]awake时只恢复depends_on已完成的步骤模型提示词加固system prompt 中加入“You must not assume any state beyond what is provided in the current event log. Always verify dependencies before proceeding.”我们选择方案 2因为它最符合 Anthropic 的设计哲学。现在awake的语义是“从最后一个 completed step 的 next step 开始”而非“从 crash point 开始”消除了歧义。5.7 问题跨 session 的上下文关联失败如“参考上次对话”现象用户说“再查下昨天那个合同”agent 无法关联到昨日 session。根因Anthropic 的 session 是完全隔离的sessionId不跨 session 传递。yesterday是模糊时间概念需外部系统解析。解决方案User Context Service构建独立服务接收user_id和time_range: yesterday查询该用户所有 session返回session_id列表Event log 关联在create session时metadata中加入related_sessions: [sess-abc, sess-def]Agent 提示词增强当用户提及时间agent 先调用get_related_sessions工具再awake相关 session 获取上下文。我们采用方案 1 2。User Context Service是无状态的用 DynamoDB 存储user_id → [session_id]映射TTL 设为 30 天。现在用户说“对比上周和这周的销售数据”agent 自动拉取两个 session 的search_sales_data结果进行对比准确率 99.2%。6. 未来半年行动清单聚焦“楼上的价值”而非“楼下的租金”Anthropic 的发布不是终点而是分水岭。接下来半年我和团队的行动重点已从“如何用好 Managed Agents”转向“如何在 runtime commoditization 的浪潮中抓住真正值钱的东西”。这份清单是我们每周站会的 check list第一Trace Store 的主权争夺本周起所有 event log 同步到自建的 LangSmith 实例非 Anthropic 托管版目标6 月底前100% 的 trace 查询走 LangSmithAnthropic API 仅作备份。评估 Brainstore 的 OLAP 能力重点测试其对“跨 session 行为聚类”如识别高频失败的工具调用链的支持。与法务协同起草《AI Interaction Log 数据主权协议》明确客户对 event log 的所有权、可移植权、删除权。第二Policy Engine 的深度集成将 OWASP Agentic Top 10 的 10 个风险项全部转化为可执行的 policy rule。例如“LLM Output Injection” 对应 ruleif output contains curl or wget then block。在 CI/CD 流水线中新增policy-scan步骤对 agent YAML 和 system prompt 运行静态分析阻断高风险配置。与客户安全团队共建 policy library将他们的 SOC2 合规要求如所有邮件必须含免责声明