<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>模型路由 on 魔都水滴</title>
		<link>https://blog.margrop.net/tag/%E6%A8%A1%E5%9E%8B%E8%B7%AF%E7%94%B1/</link>
		<description>Recent content in 模型路由 on 魔都水滴</description>
		<generator>Hugo</generator>
		<language>zh-CN</language>
		
		
		
		
			<lastBuildDate>Fri, 29 May 2026 11:24:29 +0800</lastBuildDate>
		
			<atom:link href="https://blog.margrop.net/tag/%E6%A8%A1%E5%9E%8B%E8%B7%AF%E7%94%B1/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>AI 助手为什么把一句话复读四遍：一次 OpenClaw 微信通道排障复盘</title>
				<link>https://blog.margrop.net/post/openclaw-wechat-duplicate-reply-debugging/</link>
				<pubDate>Fri, 29 May 2026 11:24:29 +0800</pubDate>
				<guid>https://blog.margrop.net/post/openclaw-wechat-duplicate-reply-debugging/</guid>
				<description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;这次问题看起来像“微信通道把同一条回复发了四遍”，但真正的重复发生在更早的位置：消息还没有进入微信发送层之前，OpenClaw Agent 的最终可见文本就已经被模型执行链路重复拼接了。排障的关键不是一上来改微信插件，而是把链路拆成发送层、会话层、模型路由层三段，用最小 prompt 复现，再比较“兼容网关路径”和“原生 provider 路径”的输出差异。最后的修复也很朴素：让个人 IM 通道显式走原生 provider，移除容易被误选的故障候选模型路径，重启 Gateway 后复测主会话。&lt;/p&gt;&#xA;&lt;p&gt;这篇文章不会出现任何真实内网地址、账号、token、会话 ID、个人微信标识或私有路径。所有配置片段都已经脱敏，并用 &lt;code&gt;&amp;lt;PLACEHOLDER&amp;gt;&lt;/code&gt; 形式表示。重点是分享一套可复用的排障方法，而不是公开某个具体环境的细节。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
			</item>
	</channel>
</rss>
