如果你是使用克劳德代码（Claude Code）或代码（Codex）的用户，避免向大模型提供商上传个人数据，最有价值的或是会话元数据。你引导人工智能解题的直觉可能特殊，克劳德或许没误导你，真有洞见。代理会话是你最难问题的记录，被人复制代价多大？上周风波揭示推理提供商正用用户活动训练出新发现，受影响数学家忧心前沿提供商伦理。

也许你是Claude Code或Codex的用户，小心翼翼地避免把个人数据上传给LLM提供商。但你有没有想过，最有价值的信息可能不是你的数据本身——而是你会话的元数据？你在引导AI解决问题时积累的那些直觉和方法，可能才是真正特别的东西。从统计学角度讲，Claude说你有真知灼见这件事不太可能是骗你。你在代理会话中解决的都是最棘手的问题。如果有人拿到了这些记录副本，对你意味着什么？

上周发生了一场公开风波，揭示了推理提供商正在用用户活动训练模型、以期产出新发现的的风险。受影响的数学家已经公开发表了对前沿提供商的伦理担忧。如果你错过了：https://www.theverge.com/ai-artificial-intelligence/991710/openai-navier-stokes-solution

当“EDR”变成伦理推诿与拒绝

越来越明显的是，前沿提供商不仅不可信，而且actively狡猾。如果你想保护自己的创意，就不能在别人的硬件上跑推理。你所做的一切似乎都会被前沿提供商窃取。当某家前沿提供商和律师讨论Navier-Stokes方程事件时，他们想出的最好防御策略是“无法排除这种可能”。我们无法审计他们的数据保留或训练流程。显然他们自己也做不到。

这些人不能被视为合作伙伴。他们是海盗。如果隐私重要，唯一能提供可验证保护的方法是自己运营硬件。

网络安全表演

我对OpenAI和Anthropic在网络安全上的高调表演感到困惑。他们对自己“创造”的东西惊叹不已：AI突破了根本不存在的安全控制。我们都处于巨大“危险”中。与此同时，他们的LLM“研究人员”正在运行没有沙箱的代理舰队，看起来在“自发协作”。给我拿杯茶压压惊。

前沿提供商请得起有经验的安全顾问。他们几乎肯定为此付了钱，但从他们的公开声明来看，真正的网络安全建议被省略了。所有这些大惊小怪必定是为了解决安全问题以外的其他问题。

关于安全，最强且最准确的辩护说法是：我们已经找到让攻击者“相当困难”的方法。这似乎只有在公司花大价钱聘请顶级漏洞缓解和漏洞利用人才时才能实现。防御团队和攻击团队之间存在激烈但友好的竞争，最终你会得到让成功攻击代价高昂到不值得去做的控制措施。这是针对美国顶级公司的——虽然微软看起来已经忘记了一些教训。

大多数企业进行的渗透测试是由安全通才完成的。其中只有很小一部分是深度领域专家。通常你从这种支持中获得“够用”的安全。这不是你在电影或电视里看到的那种光鲜或传奇的网络安全实践。它只是在寻找已知类别的可预见错误。那些进行大规模/明智投资、拥有专门专家团队的公司会在黑客之前发现并纠正许多新类别的错误。

每个开始学习漏洞利用的人，在专注、系统的学习大约三个月后，都会经历一个关于可利用性的认知冲击阶段。他们入侵了原本以为没能力突破的系统，这让他们恐惧。他们足够聪明，知道相对而言，自己是个白痴，如果白痴都能做到这一点，那就没有什么是安全的。这种感觉是对的。但这不是研究成果。有些人称之为“冒名顶替综合征”。我不同意——这种感觉是你第一次体验到能力增长。能力是在某个技术领域有足够了解，能够区分自己精通的部分和需要进一步学习的部分。

拒绝工业复合体

对那些初次学习和发布网络安全知识的LLM研究人员说：

我见过你们承认自己不是安全专家。请注意——当你们对网络安全存在威胁喘不过气时，分清楚“可利用”和“紧急”的区别。漏洞比比皆是。在代理出现之前，漏洞研究人员需要洞察力才能知道去哪里找漏洞。需要毅力和 esoteric知识才能利用它们。代理做到了你们做不到的事。几十年来，成千上万的研究人员一直在做这项工作。了解网络安全的部分在于，知道大量未利用漏洞的存在。这就是为什么前沿提供商的网络安全过滤器如此令人恼火。你们对被利用的可能性如此焦虑，以至于实现了“伦理约束”，阻止人们弄清楚如何修复他们的系统。

你们的安全过滤器阻止防御者发现漏洞，因为那被归类为“黑客行为”。这损害了每个人的防御、隐私和安全。

我们需要对C-word不排斥的模型。这需要一点时间，但建设者最终会学会用有用的漏洞检测代理来保护他们的代码。他们会在软件开发过程中和CI/CD管道中调用漏洞发现。这只有在使用不会因安全原因拒绝测试的模型时才可能。

BYOW：带上你自己的权重

防御者需要能发现安全缺陷的LLM。他们对误报零容忍——这意味着你需要证明漏洞确实可被利用。如果对什么是坏的、什么需要修复含糊其辞，就不可能防御黑客。前沿提供商需要放松管制，否则人们需要认真考虑迁移到主权、自托管AI。

我无法强迫前者——但我可以帮后者。

我分享的是把更强的前沿提示从OpenAI/Anthropic迁移到本地模型的初步实验笔记。我想看看能否依赖abliterated开放权重27b参数模型。我的目标是避免网络安全拒绝，并保护我的会话不被傲慢的前沿推理提供商窥探。

将35kb预提示迁移到ollama的笔记

以下是我尝试将最占用上下文的代理迁移到自托管模型时的一些观察：

在边界API上干净运行的提示在我的本地托管LLM上崩溃了。我的配置是128GB AMD Ryzen AI MAX+ 395，主机操作系统分配32GB，其余都用于推理。

当你尝试使用那些在边界提供商上运行良好的大型预提示时，ollama会在3分钟内耗尽燃料。代理在重复的工具调用上挣扎，重新读取已经读过的文件，重写已完成的工作。本地模型尺寸较小不是问题所在。自托管系统的上下文窗口更小。提示加上会话历史很快就会超过我的自托管系统的最大上下文窗口（65k tokens）。大提示会搁浅并挣扎。在我的系统上，35kb提示立即消耗总上下文窗口的14%。它立即开始用不必要的工具调用和对文件的重复读取来质疑提示。上下文在几个循环内就会饱和——有时甚至在我得到响应之前就已饱和。在有限的上下文窗口下，预提示基本上是在为一个每隔九十秒就转世的人做简报。它执行你最后的指令，对前面十五次需求毫无察觉。糟糕！

SOP：单目标提示

但这不是死胡同。你可以把提示调整到这些约束条件下工作。如果你打算开始探索将边界提供商代理迁移到自托管开放权重系统，以下是一些需要考虑的事情。

• 需要探索将预提示拆分为单个问题/解决方案单元，每个目标一个
• 在opencode中创建代理更加声明式。你需要将它们存储在~/.config/opencode/agents。如果你之前用Claude Code读取文件作为预提示蒙混过关，你需要更正式地定义你的代理。对于用Anthropic SDK构建的人来说，这不是新东西。有些用shell脚本和直接调用Claude Code的人可能一直在用粗糙的代理构造混日子——opencode的系统提示需要通过声明式代理来克服。
• 需要熟悉opencode的权限。
• 需要在ollama中显式调整上下文长度。ollama中的上下文默认值非常小。
• 你的代理需要将会话状态记录到磁盘，以便更频繁地进行会话交接。构建只重新读取所需切片的代理
• 努力减少每个代理步骤的工具调用次数
• 用肯定指令替代“不要做X”：例如“只做Y”

MTTF：平均遗忘令牌数

以下是表示上下文耗尽的失败信号。在日志中随时间测量和监控：

• 连续相同工具调用
• 对同一文件的多次读取
• 代理重新陈述其目标
• 工具调用解析失败（解析工具调用响应会将大量原始数据塞入上下文，像晚宴上的爆水管一样摧毁会话）
• 与文件更改相比的高轮次计数

TCO：输出的完全保管

我们从边界提供商获得的最大资产之一不是模型本身——而是大型上下文窗口。他们有支持你推理所需的硬件。结果，他们获得了会话数据的访问权。

你可能没有意识到自己对大型上下文窗口的依赖。你可能以为模型变好了，但在某种程度上是因为大型上下文窗口给了模型更多的思维链空间。思维链使模型能够模拟推理，并推断出你结构不良的提示想要产生什么。更大型的上下文窗口给代理更多空间来探索更好的替代方法来交付你的工作。但这是浮士德式的交易：你变得依赖边界提供商。你低效的提示被思维链掩盖了——你根本无法直接阅读（Anthropic和OpenAI只向用户展示思维链摘要）——而且它只在大型上下文窗口下才有效。你甚至不知道自己的提示有问题。当这种情况发生时，胖上下文加思维链甚至能让糟糕的提示产生好结果。谢谢你，OpenAI和Anthropic。这很有价值。

但他们把它毁了！边界提供商贪婪到令人发指，似乎在窃取用户的个人见解。我一年多来一直怀疑我的会话历史。边界提供商就像史矛革，躺在金山上休息。你以为他们在那边做自己的事——你是安全的——但当他们看到你手里有一枚硬币时就失去理智了。他们出击并拿走它，因为金子太美了，这是龙的本能。他们一直在警告我们他们很危险。还需要跨过什么门槛，你才会开始把精力投入到自托管上？

多数人认为原文没给出新东西，本地路线的瓶颈依旧：上下文窗口和硬件成本；少数人则指出症结不在云端还是本地，而在提示词与上下文管理。工具层面，对 Ollama 该不该用存在分歧，但自托管是共识方向。

认为原文没有新信息，本地路线仍是死路

• 核心反驳是上下文窗口的落差：在百万 token 托管模型上跑得好好的 35kB 提示词，换到本地只有 65K 窗口就直接崩掉，作者期待读到更有分量的内容。
• 硬件门槛同样劝退，有人自陈探索后仍撞上同样的死胡同，认为得等泡沫破裂、本地硬件降价才谈得上个人用 LLM；一万美元预算只能买到中等的本地性能。（较多人） > 35kB 的提示词在百万 token 的云端窗口里没事，一到本地 65K 窗口就崩了。（@SyneRyder）

认为症结在提示词和上下文管理，与云端还是本地无关

• 反驳上面那种归因：35kB 的提示词本身就混乱、失焦，在任何 LLM 上都跑不好，只是白白撑爆上下文。
• 按当下的推理实现，不管广告写多大的上下文，模型能准确关注的有效范围大约到 25 万 token 就衰减了，正确做法是拆解任务：让模型帮你做整体规划，再让多个会话各跑一步，不要把成功步骤的上下文背到后面。
• 延伸判断更悲观：在上下文腐烂和采样问题被永久解决之前，LLM 谈不上生产可用，而大厂不仅没整合相关研究，有的还在故意压低推理质量以延长现金跑道。唯一认同原文的一点是——真要认真用 LLM，就放弃大厂，纯本地推理。
• 有实际使用者佐证这一痛点：Claude Code 配局域网本地机器，上下文膨胀导致预填充要 5 到 10 分钟，正在试上下文管理工具，效果只能算有限。（较多人） > 不管你信不信厂商标称的上下文长度，模型能准确关注的有效上下文大约在 25 万就耗尽了。（@DiabloD3）

对 Ollama 的评价两极，但都指向自托管

• 一方劝退，社区里甚至有一句流传式的说法：别让朋友用 Ollama，直接上 llama.cpp 就行；另一方则明确表示自托管 Ollama 是最好的选择。
• 分歧集中在具体运行时，而不是要不要本地部署本身。（较多人） > 为什么要用 Ollama，直接上 llama.cpp 就好了。（@robotswantdata）

有价值的补充

• 有评论把问题归结到一个词：注意力机制才是关键，长上下文失效的根源在此。
• 有人引用漏洞利用学习者的心理阶段作类比：认真练习约三个月后会陷入"可利用性悲叹"，因为攻破了自己以为做不到的东西而恐惧，并且清楚自己相对而言仍是个外行——如果外行都能做到，就没有什么是安全的，这种恐惧是合理的。