1. 这不是新赛道，而是 runtime 层的“操作系统时刻”来了

你有没有试过让一个 AI 代理连续工作四十分钟，做一堆文档检索、数据比对、跨系统调用，最后在关键一步突然开始胡说八道？不是模型崩了，也不是代码错了——是它的“记忆”被挤掉了。它把最早调用 Notion API 拿到的会议纪要、从 Slack 里拉出的客户反馈、刚生成的三版方案草稿，全给悄悄抹掉了。不是报错，不是中断，是安静地、自信地、基于半截历史编造答案。等你发现时，整个会话已经不可逆地污染了，没法回放，没法审计，更没法让另一个工程师接手续上。我去年就踩过这个坑，整整两天没睡好，最后硬是把状态层从 prompt 里拎出来，塞进 Redis，再加一层 WAL 日志才稳住。Anthropic 这次发布的 Claude Managed Agents，本质上就是把我们团队当时手写的那套“状态外置+事件可溯+凭证隔离”的工程实践，做成开箱即用的托管服务。

这不是什么“AI 代理新时代”的营销话术，而是一个非常具体的、可测量的架构演进： session 不再是模型上下文的附庸，而是一个独立、持久、可查询、可恢复的一等公民 。关键词不是“agent”，而是“managed”——它管的不是模型推理，而是模型运行时的生存环境。你写 YAML 定义 agent 行为，Anthropic 提供 harness（无状态执行器）、sandbox（按需启停的隔离容器）、vault（凭证保险柜）和 event log（全链路操作日志）这四块拼图。$0.08/小时的 session 运行费，买的是这套基础设施的确定性，而不是模型本身。它解决的痛点极其真实：长周期任务的可靠性、多工具调用的安全边界、生产环境下的可观测性、以及最要命的——当 agent 突然挂掉时，你能不能在 3 秒内 resume 而不是重头再来。这背后是一整套现代分布式系统的工程直觉：把有状态的部分（session state）和无状态的部分（harness execution）彻底解耦，让故障域最小化，让恢复路径最短。它不性感，但当你凌晨三点收到告警，看到 dashboard 上清晰显示“第 7 步调用 Salesforce 失败，错误码 401，前序 6 步日志完整可查”，你会觉得这 $0.08 花得比咖啡还值。

2. 架构拆解：为什么“Session as Event Log”是真正的分水岭

2.1 Session 不是缓存，而是事实的权威记录

很多人第一反应是：“哦，就是把对话历史存数据库里？”错。Event log 的设计哲学完全不同。它不是把整个 context window 做快照，而是把每一次原子操作都作为不可变事件写入。比如一次完整的 tool call 流程，在 log 里会拆成至少四个独立事件：

1. event_type: "tool_call_requested" —— agent 决定调用 notion_search ，输入参数 {query: "Q2 sales deck", database_id: "xxx"}
2. event_type: "tool_call_executed" —— sandbox 执行成功，返回原始 JSON 结果（含所有字段，不裁剪）
3. event_type: "tool_call_result_processed" —— harness 将结果解析为结构化数据，提取出 page_id , title , last_edited_time
4. event_type: "model_response_generated" —— 模型基于处理后的数据生成自然语言回复

提示：这种粒度不是为了炫技。它直接决定了你能做什么。比如审计时，你可以精确查询“所有对 salesforce_update_contact 的调用中，哪些传入了空的 phone_number 字段”，而不用在一团混杂的文本日志里 grep。再比如调试时，你可以把 event_id: abc123 对应的 tool_call_executed 事件完整重放给开发环境的 harness，完全复现当时的输入输出，排除网络或权限干扰。

我实测过 Anthropic 提供的 /sessions/{id}/events API，返回的每条 event 都带 timestamp , sequence_number , parent_event_id （支持嵌套调用追踪），甚至 sandbox_id （关联到具体容器实例）。这已经不是简单的日志，而是构建在分布式事务语义上的操作账本。它天然支持时间旅行查询： GET /sessions/abc123/events?since=2026-04-08T14:30:00Z&limit=50 。对比传统做法——把整个 session history 当字符串塞进 PostgreSQL 的 text 字段，再用正则去扒拉“调用了什么工具”，你就明白为什么说这是质变。

2.2 Harness：无状态执行器的极致简化

Harness 的核心接口就一个： execute(name, input) → string 。注意，它返回的是 string ，不是 JSON object，不是 structured response，就是纯文本。这个设计看似倒退，实则是深思熟虑的妥协。

为什么不用强类型？因为 tool 的生态太碎片化。Notion API 返回的是 nested JSON with properties and rich_text ；Salesforce REST API 返回的是 records array with attributes ；而一个自研的内部财务系统可能只返回 CSV 格式的纯文本报表。如果 harness 强制要求所有 tool 返回统一 schema，要么开发者要写大量 adapter 代码，要么就得接受信息丢失（比如丢掉 Notion rich_text 的 formatting metadata）。Anthropic 的解法是： 把结构化解析的责任，下放到 agent 自己的 system prompt 和 reasoning 过程里 。Harness 只负责“把 input 交给 sandbox，把 stdout 拿回来”，剩下的，让 Claude 自己去 parse、去 infer、去决定下一步。

这带来两个关键好处：

1. 兼容性爆炸式提升 ：你今天用 curl 调 GitHub API，明天换用 Python requests 调内部微服务，只要输出是文本，harness 就不 care。我试过用它跑一个用 Bash 脚本调用 aws s3 ls 的 tool，返回的纯文本列表被 Claude 准确识别出文件名和大小，再据此生成清理策略。
2. 故障隔离更干净 ：如果某个 tool 的 JSON schema 突然变更（比如 Notion 加了个新字段），崩溃的只会是 agent 的 parsing logic，不会波及 harness 的执行框架。harness 永远只是个管道工，不参与业务逻辑。

注意： execute() 的 input 参数也经过精心设计。它不是 raw string，而是预处理过的 JSON object，其中 credentials 字段永远为空。真正的凭证由 Anthropic 在 sandbox 启动时注入到容器的 /run/secrets/ 目录下，且仅对该次执行有效。这意味着你在 prompt 里写 curl -H "Authorization: Bearer {{token}}" ... 是无效的——token 根本不在环境变量里，也不在 input 里。你必须用 harness 提供的 get_secret("notion_api_key") 工具来动态获取。这个细节卡死了绝大多数 credential leak 场景。

2.3 Sandbox：从“宠物”到“牲畜”的范式转移

“Sandbox as cattle, not pets” 这句话在工程圈流传已久，但真正落地的不多。Managed Agents 的 sandbox 实现了三个硬核特性：

• 秒级启停 ：官方文档称平均 1.2 秒完成 sandbox provision → execute → teardown 全流程。我用 time 命令实测了 50 次 notion_search 调用，p95 是 1.8 秒，p50 是 1.1 秒。这意味着一个需要串行调用 5 个工具的 agent，端到端延迟主要取决于网络和模型，而非 sandbox 开销。
• 资源硬隔离 ：每个 sandbox 是一个独立的 Linux namespace + cgroups v2 container，CPU quota、memory limit、network namespace 全部隔离。我故意在一个 sandbox 里跑 stress-ng --cpu 4 --timeout 60s ，同时在另一个 sandbox 调用 slack_list_channels ，后者响应时间毫无波动。这和某些“伪 sandbox”（只是用 Docker run 启个容器，但没设 resource limit）有本质区别。
• 无状态文件系统 ：sandbox 的 rootfs 是只读的，所有写操作都在 tmpfs（内存）中进行。 /tmp 下的文件在 teardown 后自动消失， /home/agent 目录每次都是全新挂载。你无法在两次 execute() 调用间通过文件系统传递状态——这强制你用 event log 或外部存储。

这个设计直接干掉了两类经典风险：

1. 横向越权 ：A agent 的 sandbox 里跑的恶意脚本，不可能读取 B agent 的 /run/secrets/notion_key ，因为每个 sandbox 的 secrets mount path 都是唯一的。
2. 状态污染 ：上次执行残留的 /tmp/cache.json 不会影响本次执行，避免了“为什么同样的输入这次结果不一样”的玄学问题。

3. 实操全景：从零部署一个生产级销售线索分配 Agent

3.1 定义 Agent：YAML 配置的实战细节

Managed Agents 支持两种定义方式：自然语言描述（适合 PoC）和 YAML（生产必备）。我们以销售线索分配为例，展示一个真实可用的 YAML：

# sales-lead-router.yaml
name: "sales-lead-router"
description: "Routes inbound leads to appropriate sales reps based on territory, product interest, and lead score"

system_prompt: |
  You are a sales operations assistant for Acme Corp. Your job is to assign incoming leads to the best-fit sales rep.
  Rules:
  - Always use 'get_lead_details' first to fetch full lead data.
  - Use 'list_reps_by_territory' to find available reps in the lead's region.
  - Use 'get_rep_capacity' to check if a rep has < 5 active leads.
  - Prioritize reps with matching product expertise (e.g., 'cloud' leads → reps with 'AWS' skill).
  - If no rep meets all criteria, assign to 'backup_queue'.
  - Output ONLY in JSON: {"assigned_to": "rep_id", "reason": "brief explanation", "confidence": 0.0-1.0}

tools:
  - name: "get_lead_details"
    description: "Fetches complete lead record from CRM by lead_id"
    input_schema:
      type: "object"
      properties:
        lead_id:
          type: "string"
          description: "The unique ID of the lead"
      required: ["lead_id"]
    # No credentials needed - this is a read-only internal API

  - name: "list_reps_by_territory"
    description: "Lists sales reps assigned to a geographic territory"
    input_schema:
      type: "object"
      properties:
        territory:
          type: "string"
          enum: ["NA-East", "NA-West", "EMEA", "APAC"]
      required: ["territory"]

  - name: "get_rep_capacity"
    description: "Returns current active lead count for a rep"
    input_schema:
      type: "object"
      properties:
        rep_id:
          type: "string"
      required: ["rep_id"]

  - name: "assign_lead"
    description: "Assigns a lead to a rep in the CRM"
    input_schema:
      type: "object"
      properties:
        lead_id:
          type: "string"
        rep_id:
          type: "string"
        notes:
          type: "string"
      required: ["lead_id", "rep_id", "notes"]

guardrails:
  max_tool_calls: 10
  max_session_duration_minutes: 15
  allowed_domains: ["acme-crm.internal", "acme-sales-api.internal"]
  disallowed_patterns:
    - "curl.*--data.*password"
    - "echo.*API_KEY"

关键细节解析：

• system_prompt 里明确写了 "Output ONLY in JSON" 。这是防止模型自由发挥的关键。我测试过，如果写成“请用 JSON 格式回复”，Claude 有时会在 JSON 前加一句“好的，这是分配结果：”，导致解析失败。必须用命令式、无歧义的指令。
• tools 的 input_schema 必须严格定义。Anthropic 会用它做 runtime validation。如果你传了 {"lead_id": "123", "extra_field": "oops"} ，harness 会直接拒绝执行并返回 400 错误，而不是让 tool 去处理脏数据。
• guardrails 是生产安全的生命线。 max_session_duration_minutes: 15 防止无限循环； allowed_domains 是网络白名单，sandbox 里任何对 google.com 的 DNS 查询都会被拦截； disallowed_patterns 是正则黑名单，能拦住 90% 的 credential 硬编码尝试。

3.2 部署与集成：如何接入现有工作流

部署不是点按钮，而是三步走：

第一步：创建 Agent 实例

# 使用 Anthropic CLI（需提前配置 API key）
anthropic agents create \
  --name "sales-lead-router-prod" \
  --yaml sales-lead-router.yaml \
  --environment "production" \
  --tags "sales,crm,integration"
# 返回 agent_id: "agnt_abc123..."

第二步：配置凭证 Vault

# 创建一个 vault，命名为 "sales-crm-vault"
anthropic vaults create --name "sales-crm-vault"

# 将 CRM API key 存入 vault（base64 encoded，实际使用时自动 decode）
echo -n "sk_live_xxx" | base64 | anthropic vaults set \
  --vault-id "vault_xyz789" \
  --key "crm_api_key" \
  --value-base64

# 关联 vault 到 agent（关键！）
anthropic agents update \
  --agent-id "agnt_abc123" \
  --vault-id "vault_xyz789"

第三步：集成到 Slack（真实场景）

# slack_integration.py
from anthropic import Anthropic
import os

client = Anthropic(api_key=os.getenv("ANTHROPIC_API_KEY"))

def handle_slack_message(event):
    # event 是 Slack 的 payload，包含 channel_id, user_id, text
    lead_id = extract_lead_id_from_text(event["text"])  # 自定义函数
    
    # 创建新 session
    session = client.sessions.create(
        agent_id="agnt_abc123",
        metadata={"source": "slack", "channel": event["channel_id"]}
    )
    
    # 发送初始消息（触发 agent）
    response = client.sessions.messages.create(
        session_id=session.id,
        content=f"New lead received: {lead_id}. Please assign."
    )
    
    # 解析 agent 的 JSON 输出
    try:
        result = json.loads(response.content)
        if result.get("assigned_to"):
            # 调用 Slack API 发送通知
            send_slack_dm(result["assigned_to"], f"You have a new lead: {lead_id}")
            return f"✅ Assigned to {result['assigned_to']}"
        else:
            return f"⚠️ Failed: {result.get('reason', 'Unknown error')}"
    except json.JSONDecodeError:
        return "❌ Agent output invalid JSON"

# 这个函数会被 Slack Events API 触发

实操心得：不要在 handle_slack_message 里做复杂逻辑。我把 extract_lead_id_from_text 写成一个极简正则 r'LEAD-(\d+)' ，因为 agent 本身就能处理模糊匹配。过度预处理反而限制了 agent 的灵活性。另外， client.sessions.create() 的 metadata 字段非常重要——它会自动注入到 event log 的每条记录里，让你后续能用 GET /sessions?filter=metadata.source:slack 精准筛选所有 Slack 来源的会话。

3.3 性能与成本实测：p50 降低 60% 是怎么算出来的

Anthropic 宣称 “p50 time-to-first-token down roughly 60%”。我用相同硬件（c5.2xlarge EC2）对比了两种方案：

方案	p50 TTFT (ms)	p95 TTFT (ms)	会话稳定性	成本估算 (1000 sessions/day)
自建 LangChain + Docker Sandbox	1240	3850	82% (因 OOM crash)	$12.50 (EC2 + EBS + monitoring)
Managed Agents	490	720	99.98% (only model errors)	$19.20 ($0.08/hr * avg 4hr/session * 1000)

计算过程：

• p50 降低 = (1240 - 490) / 1240 ≈ 60.5% —— 符合宣称。
• p95 降低 = (3850 - 720) / 3850 ≈ 81.3% —— 比宣称的 “better than 90%” 更激进（他们可能用了不同基准）。
• 成本差异的关键在于：自建方案的 $12.50 是固定成本（机器一直开着），而 Managed Agents 的 $19.20 是弹性成本（只在 session active 时计费）。但我们的监控显示，平均 session active 时间只有 3.8 分钟，远低于 4 小时上限。这意味着：
  • 低峰期成本更低 ：凌晨 2 点只有 5 个 session，自建方案仍付 $12.50，Managed Agents 只付 $0.08 * (3.8/60) * 5 ≈ $0.25 。
  • 高峰期更稳 ：促销期间 session 暴增 10 倍，自建方案需手动扩容，Managed Agents 自动伸缩。

注意：这里的 “active runtime” 指 harness 正在执行 execute() 的时间，不包括模型推理时间。模型 token 费用另计。所以总成本 = $0.08 * active_hours + Claude_token_cost 。我建议在 billing dashboard 里把这两项分开看，否则容易误判优化方向。

4. 竞争格局与避坑指南：为什么现在不是押注 runtime 的时候

4.1 四大云厂商的 Agent Runtime 已全面铺开

Anthropic 的发布被包装成“开创”，但现实是 runtime 层早已是红海。截至 2026 年 4 月，四大玩家的状态如下：

厂商	产品	GA 时间	核心特性	生态绑定	免费额度
AWS	Bedrock AgentCore	2025-11	MicroVM 隔离，8 小时 session，Policy-as-Code	LangChain, CrewAI, 自研 SDK	10M tokens/mo + 1000 session-hours/mo
Google	Vertex AI Agent Builder	2026-01	Agent Registry + Apigee 网关，支持多模型路由	LangChain, LlamaIndex	$300 赠金，含 500k session-hours
Microsoft	Azure AI Foundry	2026-02	深度集成 AutoGen/Semantic Kernel，支持 sub-agent 编排	.NET, Python SDK	12 个月免费，含 2000 session-hours/mo
Anthropic	Managed Agents	2026-04	Session-as-Event-Log, Credential Vault, YAML-first	Claude-only	无公开免费层，$0.08/hr 起

关键事实：

• AgentCore 的 SDK 下载量已达 200 万次 （AWS 官方数据），意味着大量团队已在用它跑 Claude agent。你不需要 Anthropic 的托管，也能获得几乎相同的 runtime 能力。
• Vertex 的 Agent Registry 允许你把一个 Claude agent 注册为 API，然后用 Apigee 做流量控制、配额管理、审计日志——这比 Anthropic 的原生 event log 更贴近企业 IT 的治理习惯。
• Azure Foundry 的 sub-agent 编排 是目前唯一支持“agent 调用 agent”的商业产品。比如你的销售 agent 可以直接调用一个 finance-calculator agent，而不用自己 parse 数字。

实操心得：别被“Claude-only”绑定。我在 AWS 上用 AgentCore 部署了一个 Claude agent，只改了两行代码：把 anthropic.Anthropic() 替换成 boto3.client("bedrock-agent-runtime") ，把 messages.create() 替换成 invoke_agent() 。模型推理层完全透明，runtime 层却获得了 AWS 的 IAM 权限、CloudWatch 日志、VPC 网络等全套企业级能力。这才是务实的选择。

4.2 常见问题速查表与独家避坑技巧

问题现象	根本原因	排查步骤	解决方案	我的血泪教训
Session 卡在 tool_call_requested 状态超过 2 分钟	Sandbox 启动失败（常见于 network policy 拦截）	1. GET /sessions/{id}/events 查看最后一条 event 2. 检查 event_type: "sandbox_provision_failed" 3. 查看 error_message 字段	在 agent YAML 的 guardrails.allowed_domains 中添加目标域名；或联系 Anthropic 支持开通白名单	我曾因漏加 acme-crm.internal ，导致所有 CRM 调用超时。错误日志只显示 sandbox timeout ，花了 3 小时才定位到是域名白名单问题。
Agent 返回 JSON 但字段缺失（如 assigned_to 为空）	System prompt 指令不够强硬，或 tool 返回格式异常	1. GET /sessions/{id}/events 找到 tool_call_executed 事件 2. 检查 output 字段是否为 valid JSON 3. 检查 tool_call_result_processed 是否有 parsing error	在 system_prompt 末尾加一句：“If any required field is missing, output JSON with error: 'missing field X' ”；在 tool 的 input_schema 中设 required: ["field1", "field2"]	第一次上线时， list_reps_by_territory 因网络抖动返回了空数组，agent 却继续执行，最终 assigned_to 为空。加了 error 字段后，上游系统能明确知道是 tool 故障，而非 agent 逻辑错误。
Credential Vault 里的 key 无法被 tool 访问	Tool 代码里用了错误的 secret 获取方式	1. 检查 tool 代码是否调用 get_secret("key_name") 2. 检查 anthropic agents update 是否正确关联了 vault	确保 tool 代码使用 Anthropic 提供的 get_secret() 函数（非 os.getenv() ）；确认 vault_id 和 agent_id 关联无误	我曾把 get_secret() 写成 get_secret_value() ，函数不存在，sandbox 直接 crash。错误日志里只显示 command not found ，根本看不出是函数名错了。
Event log 里看不到某次 tool call 的详细输出	Harness 的 execute() 返回了非 string 类型	1. 检查 tool 的 stdout 是否被重定向 2. 检查 tool 是否调用了 print(json.dumps(...)) 而非 print(...)	所有 tool 的最终输出必须是 UTF-8 编码的纯文本。如果要输出 JSON，必须 print(json.dumps(data, ensure_ascii=False))	一个 Python tool 用了 pprint.pprint(data) ，输出带换行和缩进的格式化 JSON，导致 harness 解析失败，event log 里只有 output_truncated: true 。改成 print(json.dumps(data)) 后一切正常。

4.3 价值迁移的三层地图：在哪里下注才不被淘汰

Runtime 层 commoditization 的历史规律很清晰：当基础设施足够好、足够便宜、足够标准时，钱就会流向它上面的抽象层。当前 AI 工具栈的价值迁移已明确指向三层：

第一层：Trace Store（追踪存储）—— 你的 agent 的“黑匣子”

• 为什么重要 ：当 runtime 可以随时切换（今天用 Anthropic，明天迁到 AWS），唯一不变的是 what the agent actually did 。Trace store 就是这个事实的唯一真相源。
• 现状 ：Braintrust 的 Brainstore（OLAP 优化）、Arize 的 Phoenix（开源 Apache 2.0）、LangSmith（LangChain 生态捆绑）三足鼎立。
• 我的选择 ：用 LangSmith。不是因为它最好，而是因为它的 langchain SDK 已深度集成到所有主流框架。我只需在 agent 初始化时加一行 langsmith_client = Client() ，所有 invoke() 调用自动记录 trace。迁移成本趋近于零。

第二层：Governance & Policy（治理与策略）—— 企业的“AI 宪法”

• 为什么重要 ：采购部门不会问“你的 sandbox 多快”，但会问“这个 agent 能不能修改生产数据库？谁审批过？审计日志保留多久？”
• 现状 ：AWS AgentCore 的 Policy-as-Code 已 GA；OWASP Agentic Top 10 刚发布 1.0 版；微软正在将 Azure Policy 扩展到 agent action level。
• 我的动作 ：在所有 agent YAML 的 guardrails 里，除了基础限制，额外加上 policy_id: "acme-sales-lead-v1" 。这个 ID 会写入 event log，后续用 Trace Store 查询时，可以 SELECT * FROM events WHERE policy_id = 'acme-sales-lead-v1' ，实现策略执行的可审计。

第三层：Vertical Agent Marketplaces（垂直领域 Agent 商店）—— 解决“我能用它干什么”的终极问题

• 为什么重要 ：企业不为“runtime”付费，只为“解决销售线索分配”付费。Salesforce Agentforce $800M ARR 证明了这一点。
• 现状 ：GitHub 上已有 ai-hedge-fund （金融）、 pentagi （安全）、 healthcare-claims-agent （医疗）等成熟开源项目。
• 我的策略 ：不自研通用 agent，而是基于 ai-hedge-fund 的代码，定制化我们的 acme-finance-research-agent 。用 Anthropic Managed Agents 作为 runtime，但核心价值在垂直领域的 prompt engineering、tool 集成、和业务规则封装。这样，即使 runtime 换成 AWS，我的 agent 代码几乎不用改。

5. 终极判断：这不是技术发布会，而是价值重估的起始信号

Anthropic 这次发布，表面看是产品更新，实质是一次行业价值坐标的重新校准。它像一面镜子，照出了整个 AI 基础设施层正在发生的深刻位移： runtime 正在从“高价值产品”蜕变为“隐形基础设施” 。这和二十年前 VMware ESX 的命运惊人相似——当年卖几十万美元一套的虚拟化软件，如今已是云厂商免费赠送的底层能力。Anthropic 的 Managed Agents，就是那个 2005 年的 VMware：技术扎实，架构优雅，定价合理，但它的历史使命，不是成为下一个十年的统治者，而是加速那个统治者的到来。

我亲手部署过三个版本的 agent 系统：2023 年用 LangChain + 自建 Docker，2024 年迁移到 AWS AgentCore，2026 年又试了 Anthropic Managed Agents。每一次迁移，我花在“让 runtime 工作”上的时间越来越少，而花在“定义业务逻辑、设计 tool 接口、编写 system prompt”上的时间越来越多。这印证了一个朴素真理： 当底层足够可靠，工程师的注意力就会自然上浮到更高阶的抽象 。现在，这个上浮已经清晰可见——Trace Store 在融资，Policy Engine 在标准化，Vertical Agent 在 GitHub 上星标暴涨。

所以，如果你是一家初创公司的 CTO，正在评估是否要押注 Anthropic 的 runtime，我的建议很直接： 用，但别信 。用它快速验证你的 agent 逻辑，享受它带来的稳定性和可观测性；但别把它当作护城河，更别指望靠 runtime 差异化建立长期优势。真正的护城河，在你为销售线索分配写的那 200 行 prompt 里，在你对接 CRM 的 5 个 tool 的精准 schema 里，在你定义的 acme-sales-lead-v1 policy 里。这些才是 runtime 之上的、难以被 commoditize 的价值。

最后分享一个我上周的真实经历：我们用 Anthropic Managed Agents 跑一个客服 agent，p95 响应时间稳定在 800ms。但客户投诉率没降——因为 agent 总是把“退款申请”归类为“一般咨询”。我们花了三天时间，不是优化 sandbox，而是重写了 system prompt，加入了 12 个退款相关的关键词和否定词，并用 50 个历史 case 做了 few-shot 示例。上线后，投诉率下降了 63%。你看， 让 agent 做对事，永远比让它做得快更重要 。而“做对事”的能力，从来不在 runtime 层，而在你对业务的理解里。