TPClaw v1.1.0 的重点不是再造一个聊天壳，而是把智能体在生产环境里最容易踩坑的几件事往运行时里收：模型能不能按会话临时切换，供应商挂了能不能继续答，流式输出断了能不能补救，以及 skill 能不能自动进化。
它基于 RuleGo 规则引擎和 RuleGo AI 智能体框架构建，核心说法是：规则链即智能体，智能体即服务。这个定位很工程化——不是只讨论 prompt，而是把记忆、协作、路由和容错都放进可编排的链路里。
会话级模型切换：不要把模型选择写死在全局配置里
很多 Agent 系统早期都会把模型配置写成全局变量：全站默认一个大模型，必要时再改环境变量。问题是，一旦进入真实业务，同一个用户会话里可能需要临时换模型：
- 普通问答用便宜模型；
- 长推理任务切到更强模型；
- 敏感业务走指定供应商；
- 某个会话正在排障，需要固定模型复现问题。
TPClaw v1.1.0 提到的会话级模型临时切换，价值就在这里：模型选择不再只是部署参数，而是会话状态的一部分。这样做的好处是粒度更细，代价是状态管理更复杂：你需要清楚记录每个 session 当前使用的模型、供应商、思考强度，以及切换发生的原因。
一个实用原则是：全局配置给默认值，会话配置只保存差异。否则会话状态会越来越胖，排查时也更难判断到底继承了哪些策略。
统一调节思考强度：给推理成本装一个旋钮
v1.1.0 还强调了思考强度的统一调节。这个能力适合放在 Agent 编排层，而不是散落在每个工具调用或 prompt 模板里。
可以把思考强度理解成一个抽象档位，而不是绑定某家模型的具体参数：
low：快速响应，适合 FAQ、摘要、格式转换；medium：默认档，适合多数业务助手；high：复杂规划、代码分析、多步骤任务。
这样做的关键是把业务语言和模型参数解耦。今天某个供应商叫 reasoning effort，明天另一个供应商叫 thinking budget，Agent 层都可以统一翻译。调用方只需要说：这个会话现在要高强度思考。
风险也很明确：思考强度越高，延迟和成本通常越不可控。建议为不同租户、不同业务线设置上限，不要让前端随便把所有会话都调到最高档。
供应商故障转移：Agent 服务不能只相信一家模型
备用供应商故障转移是这次发布里很生产化的一项能力。大模型服务的失败并不稀奇：限流、网络抖动、区域故障、模型临时下线、返回格式异常，都可能让一次 Agent 执行中断。
一个可操作的故障转移策略通常要回答四个问题：
- 什么错误可以重试？例如超时、429、5xx。
- 什么错误不能重试？例如权限错误、请求格式错误。
- 备用供应商是否等价？上下文窗口、工具调用、JSON 输出能力可能不同。
- 流式输出已经开始后怎么办？这就是 mid-stream 流式重试要处理的问题。
mid-stream 重试比普通重试麻烦，因为用户可能已经看到了前半句。工程上要避免重复输出、语义断裂和工具调用重复执行。更稳妥的方式是让流式层维护 chunk 序号或输出缓冲，在切换供应商后从一个可控边界继续，而不是简单地重新打一遍完整请求。
可以这样实践：用 YAML 描述会话模型路由与故障转移
下面示例不是 TPClaw 官方配置格式，而是一个可以借鉴的最小配置模型：把默认模型、会话覆盖、思考强度映射和供应商故障转移写清楚。你可以把它改造成自己的 Agent 网关、RuleGo 节点配置或服务端路由规则。
# tpclaw-routing.example.yaml
# 假设你的 Agent 网关会读取这个文件，并在每次会话请求时合并策略。
model_policy:
default_model: fast-chat
default_vendor: vendor_a
default_thinking: medium
thinking_map:
low:
max_tokens: 1024
reasoning_budget: small
medium:
max_tokens: 4096
reasoning_budget: normal
high:
max_tokens: 8192
reasoning_budget: deep
sessions:
s-10086:
model: deep-reasoner
vendor: vendor_a
thinking: high
reason: temporary switch for debugging a planning task
s-10087:
model: fast-chat
vendor: vendor_b
thinking: low
reason: vendor_a is rate limited for this tenant
failover:
enabled: true
retryable_errors:
- timeout
- rate_limited
- upstream_5xx
max_attempts: 3
providers:
vendor_a:
fallback:
- vendor_b
- vendor_c
vendor_b:
fallback:
- vendor_c
streaming:
mid_stream_retry: true
chunk_checkpoint_interval: 20
duplicate_guard: true
如果把它落成服务端逻辑，可以按下面的顺序执行：
# 1. 读取全局默认策略
# 2. 按 session_id 合并会话覆盖项
# 3. 将 thinking 档位翻译成目标供应商参数
# 4. 调用首选供应商
# 5. 遇到可重试错误时切到 fallback provider
# 6. 流式输出时根据 checkpoint 做去重和续写
这里最重要的不是 YAML 本身，而是把策略显式化。很多 Agent 事故不是因为没有重试，而是因为重试策略藏在代码分支里，线上没人知道一次回答到底换过几次模型、经过几个供应商。
skill 自动进化：有用，但要加护栏
摘要中提到自动进化 skill，这是 Agent 平台很有吸引力的一点。一个会干活的智能体不应该每次都从零开始，它应该能沉淀工具使用经验、任务拆解方法和团队协作模式。
但自动进化也意味着风险：
- 错误经验被固化；
- skill 版本不可追踪；
- 自动生成的规则影响生产链路；
- 多智能体协作时出现职责漂移。
建议把 skill 进化当成代码变更来管：有版本号、有评审、有回滚、有灰度。自动生成不等于自动上线。比较安全的做法是先进入候选 skill 池，通过离线评测或小流量会话验证，再合并到正式规则链。
落地检查清单
如果你准备评估 TPClaw v1.1.0 或类似的 Agent 运行时，可以重点看这些点：
- 会话级模型切换是否可审计，是否能看到谁在什么时候切了什么模型；
- 思考强度是否有租户级、业务级上限；
- 故障转移是否区分可重试和不可重试错误；
- mid-stream 重试是否处理重复 chunk、半截回答和工具重复执行；
- skill 自动进化是否有版本管理、评测和回滚；
- 规则链是否足够可视化，方便团队协作排障。
TPClaw v1.1.0 的方向很清晰：把 Agent 从演示程序推向可运营服务。模型能力当然重要，但真正决定能不能上线的，往往是这些不显眼的运行时能力：路由、记忆、容错、审计和协作。