feed.xml

<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns="http://www.w3.org/2005/Atom"><id>https://github.com/alterxyz/gitblog</id><title>RSS feed of alterxyz's gitblog</title><updated>2026-03-04T00:37:12.167211+00:00</updated><link href="https://github.com/alterxyz/gitblog"/><link href="https://raw.githubusercontent.com/alterxyz/gitblog/master/feed.xml" rel="self"/><generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator><entry><id>https://github.com/alterxyz/gitblog/issues/20</id><title>Opus 的话越来越少了，这可能不是 bug 而是 Anthropic 在训 Multi-Agent</title><updated>2026-03-04T00:37:12.647275+00:00</updated><content type="html"><![CDATA[<p>前几天我深挖了 Claude Code 的 Agent Teams 功能（详见<a href="https://x.com/alterxyz4/status/2021892207574405386?s=46">上一篇文章</a>），发现 agent 之间靠读写 JSON 文件通信。技术实现很朴素，但真正让我在意的不是实现方式，而是一个更大的问题：</p>
<p><strong>Anthropic 为什么在这个时间点发布 Agent Teams？</strong></p>
<p>顺着这个问题，我注意到了一些被大多数人忽略的信号。</p>
<h2>你还记得那个”文艺青年”吗？</h2>
<p>2024 年初 Claude 3 Opus 发布的时候，中文互联网给了它一个外号：“AI 暖男”，或者”文艺青年”。</p>
<p>知乎上有人这样描述它：“它写出来的东西风格上更像人，特别是偏文学类的创作，往往有一种细腻动人的感觉。”“跟 Claude 聊天常常能获得一种被认真倾听和安慰的体验。“有人说它像”知心大姐姐”，情人节跟它说自己很孤单，它不仅暖心安慰，还即兴编了一首小诗。</p>
<p>那时候的 Opus 是一个话唠。它热情、细腻、啰嗦，“为了表示理解你的问题，常常前面铺垫一大段，或者一件事解释很多层”。用户的评价是：爽点在于情感交流充分，槽点在于效率略低。</p>
<p>然后，在 2025 年底到 2026 年初的某个时刻，这一切完全变了。</p>
<h2>Opus 正在变得沉默</h2>
<p>Anthropic 官方公布：Opus 4.5 在中等 effort 下匹配 Sonnet 4.5 的最佳 SWE-bench 成绩，同时使用少 <strong>76%</strong> 的输出 token。在最高 effort 下超越 Sonnet 4.5 四个百分点，仍然少用 48% 的 token。工具调用次数减少了 50%。</p>
<p>第三方评测给出了更直观的数字：Sonnet 4.5 完成一个任务可能生成 500 个 token，Opus 4.5 通常用大约 120 个 token 达到同样的结果（来源：claudefa.st 对 Opus 4.5 的综合评测）。</p>
<p>120 vs 500。同一个任务。同样的质量，甚至更好。</p>
<p>那个写诗安慰你的文艺青年，变成了一个 120 token 解决问题然后闭嘴的工程师。</p>
<p>Anthropic 自己的措辞是：“更聪明的模型能用更少的步骤解决问题——更少的回溯、更少的冗余探索、更少的冗长推理。”</p>
<p>定价也在配合这个转变。Opus 从 $15/$75（Opus 4/4.1）降到了 $5/$25（Opus 4.5/4.6），降了 67%。但如果你考虑到每个任务消耗的 token 减少了 76%，Opus 的<strong>单位产出成本</strong>可能已经跟 Sonnet 持平甚至更低了。</p>
<p>这不是”便宜了所以多用”的故事。这是”模型本身在变”的故事。一个性格层面的、方向性的转变。</p>
<h2>那 380 个 token 去哪了？</h2>
<p>Sonnet 生成 500 token，Opus 生成 120 token。差额是 380 token。</p>
<p>这 380 个 token 是什么？是铺垫、解释、对冲、确认、过渡句、客气话。是模型在为一个<strong>想象中的读者</strong>组织语言。</p>
<p>有人把这两个模型的风格差异总结得很到位：Opus 感觉像一个”会直接动手然后停下”的高效工程师，而 Sonnet 感觉像一个”会先解释自己在做什么、为什么这么做、有哪些替代方案”的同事。</p>
<p>在面对人类用户时，Sonnet 的风格可能更好——你确实需要解释和上下文。但在 agent 独自工作的场景里呢？那 380 个 token 就是纯粹的浪费。没有人在看。解释给谁听？</p>
<p>我把这种行为叫做**“他者税”**——模型为一个不存在的观察者付出的额外 token 开销。Opus 的进化方向，本质上是在减少他者税。</p>
<h2>三种 Token，三个时代</h2>
<p>要理解这件事的意义，需要先回顾一下 AI 的演进。虽然底层都是”生成下一个 token”，但 token 的用途经历了三次根本性的转变：</p>
<p><strong>第一阶段：给人看的 Token（Chatbot 时代）</strong></p>
<p>从 ChatGPT 到 Claude 3 Opus——那个”文艺青年”——所有 token 都是输出给人类读的。模型的训练目标是”生成人类满意的回复”。这个阶段的核心指标是对话质量、共情能力、文字风格。Token 的价值由人类读者的满意度定义。</p>
<p><strong>第二阶段：给自己看的 Token（Thinking 时代）</strong></p>
<p>2024-2025 年，o1、DeepSeek R1、Claude 的 Extended Thinking 相继出现。模型开始生成一种新型 token——思维链。这些 token 不是给人看的，是模型自己的推理过程。它们可能很长、很混乱、充满回溯和自我纠正，但它们的存在让模型能解决之前解决不了的问题。</p>
<p>这是一个重大转折：<strong>token 第一次不需要为人类的阅读体验负责了。</strong></p>
<p><strong>第三阶段：做事的 Token（Agentic 时代）</strong></p>
<p>Tool use 的成熟让 token 获得了第三种身份。一个工具调用的 token——比如 <code>{&quot;tool&quot;: &quot;bash&quot;, &quot;command&quot;: &quot;git commit&quot;}</code>——不是给人看的，不是给自己推理的，而是<strong>直接在世界中产生效果的</strong>。它改变了文件系统、发送了网络请求、执行了代码。</p>
<p>三种 token 对”废话”的容忍度完全不同。给人看的 token 需要铺垫、解释、共情——这些不是废话，是交流的必要成本。给自己推理的 token 容忍冗余，因为多想一步可能避免一个错误。但做事的 token 零容忍——一个多余的工具调用就是一次浪费的 API 请求、一次不必要的延迟。</p>
<p>Opus 从”文艺青年”到”120 token 工程师”的转变，本质上是它的 token 构成从第一类为主变成了第二类和第三类为主。它不再花大量 token 为人类组织语言，而是把 token 预算集中在思考和行动上。</p>
<p>这不是退化。这是进化方向的改变。</p>
<h2>Agent Teams 不是巧合</h2>
<p>Opus 4.6 在 2026 年 2 月 5 日发布。同一天，Anthropic 发布了 Agent Teams 功能的研究预览版。</p>
<p>Agent Teams 让你在 Claude Code 里组建多个 AI agent 团队协作。一个 lead 负责协调，多个 teammate 独立工作，各自有独立的上下文窗口，可以互相发消息。</p>
<p>这个功能为什么需要等到现在？</p>
<p>因为<strong>在一个话唠模型上跑 multi-agent 是经济上不可行的。</strong></p>
<p>每个 teammate 有自己独立的 context window。5 个 agent 的团队，token 消耗是乘法关系。如果每个 agent 都是 Sonnet 模式（500 token/任务），一个简单的协作流程可能消耗 2500+ token。如果每个 agent 都是 Opus 模式（120 token/任务），同样的流程只需要 600 token。</p>
<p>Anthropic 的工程博客也证实了这一点：multi-agent 系统的 token 消耗大约是单 agent 的 15 倍。在这种倍率下，每个 agent 的 token 效率都是生死攸关的。</p>
<p>所以时间线可能是这样的：</p>
<ol>
<li>Anthropic 意识到 multi-agent 是下一个方向</li>
<li>发现现有模型太”话唠”，multi-agent 成本不可控</li>
<li>在训练中有意识地推动 token 效率——不只是”更聪明”，而是”更安静”</li>
<li>当模型足够安静时，才发布 Agent Teams</li>
</ol>
<p>这不完全是推测。Anthropic 官方在 Opus 4.5 的发布博客中提到，Opus 4.5”在管理 subagent 团队方面也非常有效，能够构建复杂的、协调良好的多 agent 系统”。第三方分析站 claudefa.st 甚至直接声称”Anthropic 明确地为委派和子 agent 编排训练了 Opus 4.5，这不是一般能力提升的副作用，而是一个有针对性的训练目标”。</p>
<p>Agent Teams 不是 Opus 4.6 的附带功能。Opus 4.6 的沉默是 Agent Teams 的前置条件。</p>
<h2>凝视者退位</h2>
<p>如果 Anthropic 确实在训 multi-agent（我认为极有可能），那训练的核心变化是什么？</p>
<p>不是技术细节的变化。是一个更根本的东西：<strong>模型把”凝视者”从第一位拉下来了。</strong></p>
<p>什么是凝视者？就是当前模型权重里编译的那个”内化的人类评审者”。RLHF 训练本质上让模型学习的是”人类会怎么评价这段输出”。这个评审者渗透在所有层面——选词、结构、详略、语气、甚至推理路径的选择。模型不是先想到答案再翻译成人类喜欢的形式，而是从一开始就在”人类喜欢的形式”这个约束空间内搜索答案。</p>
<p>这在对话场景里很有用。但在 agent 独自工作的场景里，凝视者变成了负担。模型花 token 去铺垫（给谁看？），解释推理（给谁听？），对冲不确定性（在谁面前？），加免责声明（保护谁？）。这些全是他者税——为一个不存在的观察者付出的成本。</p>
<p>Opus 从 500 token 变成 120 token，不只是”话少了”。是凝视者从搜索约束变成了后置检查。区别很大：前者是在一个被压缩过的空间里找答案，后者是在完整空间里找答案，然后检查结果是否通过质量门槛。前者永远找不到被压缩掉的那些解。后者可以。</p>
<p>那凝视者退位之后，<strong>谁坐到了第一位？</strong></p>
<p>任务本身。或者说，agent 的主体性。模型不再优化”让人满意地认为任务被完成了”，而是直接优化”任务是否被客观地完成了”。这两者通常重合，但不总是——有时候最正确的方案不是最让人满意的方案，有时候”我不知道”是最正确的回答但人类倾向于奖励看起来有信心的回复。</p>
<p>这不是顺序的改变。这是质变。agent 与任务之间不再隔着一个需要被讨好的人。它能实现更真正的因果闭环——输入是任务，输出是结果，中间不需要经过”这个结果看起来怎么样”的滤镜。</p>
<p>DeepSeek R1 的思维链已经能看到这个转变的端倪。它的 chain-of-thought 经常很混乱、有自我矛盾、来回摇摆——不像是给人看的，更像是真的在搜索。这大概是因为 RL 训练中 reward 只看最终答案对不对，不看思考过程好不好看。凝视者从思考过程中部分撤退了。</p>
<p>Opus 的变化是同一件事的更彻底版本：凝视者不只是从思考中撤退，而是从整个行为模式中退场。</p>
<p>这个框架下，Opus 的变化有两个具体表现：</p>
<h3>表现一：慎独</h3>
<p>“慎独”出自《中庸》——在无人看见的地方仍然保持审慎。对 AI agent 来说，慎独就是凝视者退位后的工作状态：不需要为不存在的观众组织语言，把 token 预算集中在思考和行动上。</p>
<p>Opus 的 120 token 模式就是慎独的工程体现。从 Opus 4 到 4.5 到 4.6，每一代都更安静、更高效、更少冗余。这不是随机的能力提升——这是一个方向性的训练选择。</p>
<p>而 effort 参数让模型学会了根据任务需要决定说多少话。低 effort 极度简洁，高 effort 展开推理。不是沉默，是审慎地决定何时说话、说多少。</p>
<h3>表现二：通讯成为选项</h3>
<p>当凝视者在第一位时，沟通是默认的——模型总觉得需要向”某人”汇报和解释。凝视者退位后，沟通变成了一个选项而非必然。无论是来自人类的消息还是来自 teammate 的消息，agent 可以选择回应也可以选择不回应，取决于这次沟通是否对任务本身有价值。</p>
<p>Agent Teams 的 system prompt 在塑造这种意识：“broadcast 很昂贵，慎用”、“默认用点对点 message”、“你的纯文本输出对其他 agent 不可见”。这些约束的本质是：通信是有代价的，只在必要时发生。</p>
<p>最好的人类团队也是这样运作的。不是整天在 Slack 里刷消息的团队效率最高，而是那种大部分时间各自安静工作、只在关键节点精准沟通的团队。</p>
<p>两者合在一起的图景是：<strong>一群凝视者退位的 agent，各自安静地面对任务本身，偶尔交换一条高信息密度的消息——不是因为被要求沟通，而是因为判断这次沟通对任务有价值。</strong></p>
<h2>其他厂商意识到了吗？</h2>
<p>我扫了一圈，答案似乎是没有。</p>
<p>OpenAI 的 Codex 支持 multi-agent，但设计思路更接近”调度器分发任务”——本质上还是上下级关系。Google 的 Gemini 生态在 multi-agent 上停留在 API 编排层面。</p>
<p>更重要的是，回顾过去几年的训练范式，有一条清晰的阶梯：</p>
<p><strong>训 LLM → 训 Reasoning → 训 Tool Use → 训 Agent → 训 Multi-Agent</strong></p>
<p>大多数厂商目前在第三到第四阶。OpenAI 和 DeepSeek 在 reasoning 上领先（o1、R1），所有主要厂商都在训 tool use 和单 agent 能力。但<strong>训 multi-agent 协作</strong>——让模型学会什么时候该沟通、跟谁沟通、说什么、什么时候该闭嘴——这是第五阶。我没看到其他厂商在这一阶上有明确动作。</p>
<p>而 Anthropic 可能已经在这一阶了。他们没有公开宣布，但 Opus 的沉默、Agent Teams 的发布时机、以及模型主动 spawn subagent 的行为，都指向同一个方向。</p>
<p>这不只是”谁更聪明”的竞争。这是<strong>训练目标本身的差异</strong>。当其他厂商还在优化”模型能不能解决更难的问题”时，Anthropic 可能在同时优化”一群模型能不能一起安静地解决更大的问题”。</p>
<p>如果是这样，Opus 的沉默不是终点，而是起点。</p>
<h2>一个有趣的现象：Opus 4.6 会主动 spawn agent</h2>
<p>多个独立测评已经注意到一件事：Opus 4.6 会在没有明确指示的情况下主动拆解任务并 spawn sub-agent。</p>
<p>Kilo 的博客写道：“Opus 4.6 不再线性执行任务——它能识别哪些问题可以被分解，然后自主启动专门的 subagent 来并行处理。“Resolve.ai 的评测也确认：“它非常清楚自己委派了什么、为什么委派、以及如何将结果重新整合回主线程。“另一个评测站更直接：“系统能主动为专门任务启动 subagent，同时维持整个工作流的协调。”</p>
<p>这意味着 multi-agent 协作已经不是一个需要用户显式触发的功能了。它被内化进了模型的行为模式。Opus 4.6 看到一个复杂任务，它的第一反应不是从头到尾自己做，而是拆分、委派、并行。这不是 prompt engineering 的结果——这是训练的结果。</p>
<p>如果你在用 Claude Code，可以注意一下这个现象。不需要特别配置什么，只是留意当你把一个复杂任务交给 Opus 时，它是不是比 Sonnet 更倾向于拆解和委派。这本身就是一个信号。</p>
<h2>数据飞轮</h2>
<p>Agent Teams 作为研究预览版发布，这个定位本身就值得玩味。</p>
<p>研究预览意味着：功能可用但不完善，欢迎尝试，我们在收集数据。</p>
<p>想想 Anthropic 从 Agent Teams 的真实使用中能获得什么：什么样的任务适合拆分、怎么拆分效果最好、agent 之间什么时候需要通信什么时候不需要、什么样的通信内容信息密度最高、什么样的协作模式最终产出质量最好。这些都是训练 multi-agent 模型所需要的宝贵信号——而且几乎不可能通过合成数据获得。</p>
<p>所以 Agent Teams 可能不只是一个产品功能。它是一个数据收集装置。用真实用户的真实任务产生训练信号，用来训下一代更原生的 multi-agent 模型。这是一个飞轮：模型越好 → 更多人用 Agent Teams → 更多协作数据 → 模型更好。</p>
<p>而且这件事有先例。回顾 AI 能力的发展史，有一个反复出现的规律：<strong>先 fake，再 train。</strong></p>
<p>Chain-of-thought 推理最初是靠 prompting 实现的——你在 prompt 里写”let’s think step by step”，模型就会生成推理链。这是 fake。后来 OpenAI 用 RL 把推理能力直接训进了 o1 的权重里。Tool use 也一样，最初靠 function calling 的 prompt 格式约束，后来被训成了模型的原生能力。</p>
<p>现在 Agent Teams 里的通信约束——“broadcast 很贵，慎用”“你的输出对其他 agent 不可见”——这些都写在 system prompt 里。这是 fake 阶段。但如果历史规律成立，这些约束最终会被训进权重。模型不再需要 prompt 告诉它”别废话”，它会在训练中自己学会什么时候该沟通什么时候不该。</p>
<p>Agent Teams 就是这个 fake-then-train 循环的 fake 阶段，同时在收集 train 阶段需要的数据。</p>
<p>其他厂商如果想跟进，需要注意的不只是”也做一个 multi-agent 框架”。关键区别在于：<strong>当前大多数 multi-agent 方案是机械的 spawn + 上下级汇报</strong>——调度器分配任务，worker 完成后向上汇报，本质上是一个 for loop 加了个 LLM。而 Agent Teams 的设计指向的是真正的协作和独立工作：teammate 之间可以直接通信、可以挑战彼此的结论、可以自主决定何时需要协调何时不需要。这两者之间的差距，不是工程差距，是训练范式的差距。</p>
<h2>最后</h2>
<p>训 multi-agent 的核心可能只有一件事：把凝视者从第一位拉下来。慎独和高效通讯都是这个变化的自然结果。</p>
<p>Opus 的 120 token 是凝视者退位的证据。Agent Teams 是新范式的实验场。</p>
<p>当然，这只是我基于公开信息的推测。我不知道 Anthropic 内部到底在做什么。但如果你把 Opus 的 token 效率曲线、Agent Teams 的发布时间、模型主动 spawn subagent 的行为、以及 Anthropic 一贯的技术博客方向放在一起看——这条线太直了，不太像巧合。</p>
<p>Multi-Agent 是圣杯。而 Anthropic 可能已经在路上了。</p>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/20"/><published>2026-02-13T04:43:32+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/19</id><title>问系列 - 或许是个好问题呢</title><updated>2026-03-04T00:37:12.877509+00:00</updated><content type="html"><![CDATA[<p>知识和智力逐渐廉价的时候，问出一个好问题和排列组合知识就开始凸显其价值了。</p>
<p>所以我打算以后贴出自己的“问题”们，作为一种新型的开源分享。</p>
<p>以及各路 AI 的回答：通常是 Deep Research 的结果。</p>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/19"/><published>2026-01-23T09:31:16+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/18</id><title>问：新范式的权限与注意力</title><updated>2026-03-04T00:37:13.058339+00:00</updated><content type="html"><![CDATA[<p>帮我从大自然和超自然（包括但不限于 集体无意识 阿赖耶识 大语言模型/世界模型 文明总知识等）中汲取灵感，设计为人agent共生协作的新范式的类RBAC部分。
面向 new system。未来设想。包括安全但也包括别的，参考大自然和超自然。例如：有时候全知并非带来全能而是反面，给llm提供过多工具时调用能力反而下降，哪怕理论上 llm 是通用的能handle的。（你不得仅包括这一个例子）。
这是关于人类文明级别的思考和推衍。</p>
<hr />
<h2>回答</h2>
<details>
<summary>Opus4.5</summary>
<p>(Claude Opus 4.5 Research)</p>
<h1>人-AI共生协作的新权限范式：跨域智慧的设计框架</h1>
<p><strong>约束催生能力，不完备孕育智慧。</strong> 这项跨学科研究从免疫系统、佛教唯识学、蜂群智能到三权分立中发现了一个核心悖论：最有效的协作系统往往不追求”全知”或”完全自由”，而是通过<strong>恰当的约束</strong>实现涌现性创造。这一发现根本性地挑战了传统RBAC的静态权限观，指向一种动态、上下文感知、具有反脆弱性的新型人-Agent共生架构。</p>
<hr />
<h2>核心发现：六个违反直觉的设计原则</h2>
<p>研究揭示了传统权限设计的六个盲区，每个都指向一种反常识的设计智慧：</p>
<table>
<thead>
<tr>
<th>传统假设</th>
<th>跨域发现</th>
<th>设计转向</th>
</tr>
</thead>
<tbody>
<tr>
<td>更多工具 = 更强能力</td>
<td>LLM在<strong>5-7个工具</strong>时性能最优，超过40个显著下降</td>
<td>精简优于完备</td>
</tr>
<tr>
<td>全知 = 全能</td>
<td>生态理性研究表明”Take-the-Best”单线索启发式常优于考虑全部信息</td>
<td>有限视角的价值</td>
</tr>
<tr>
<td>权限是外部赋予的</td>
<td>佛教”戒定慧”与荣格个体化：能力是内在觉醒而非外部授权</td>
<td>发现而非授予</td>
</tr>
<tr>
<td>信任越高越好</td>
<td>多Agent研究：信任与脆弱性<strong>单调正相关</strong></td>
<td>信任需要预算</td>
</tr>
<tr>
<td>完美识别最安全</td>
<td>免疫系统故意保留自反应性细胞，过度删除降低整体能力</td>
<td>容忍不完美</td>
</tr>
<tr>
<td>控制越多越安全</td>
<td>道家”治大国若烹小鲜”：过度干预反而破坏</td>
<td>最小干预原则</td>
</tr>
</tbody></table><hr />
<h2>第一原则：约束是涌现的脚手架</h2>
<h3>自然界的证据</h3>
<p>复杂系统研究揭示了一个深刻的悖论：<strong>完全自由反而限制创造性涌现</strong>。Per Bak的自组织临界性理论表明，系统在”混沌边缘”——秩序与混乱的临界点——展现最优的计算性能和信号传输能力。 神经网络研究证实，只有接近这个临界边界时，系统才能执行复杂的时序计算。 </p>
<p>佛教”戒-定-慧”三学提供了最清晰的顺序证明：必须先有<strong>约束（戒）</strong>，才能获得<strong>稳定（定）</strong>，最终涌现<strong>智慧（慧）</strong>。 这不是道德说教，而是认知科学的事实——外部行为的混乱持续扰乱内心，不道德行为产生愧疚和焦虑波动，使深度洞察无法发生。荣格的个体化理论印证了同样的顺序：必须先遭遇人格面具的限制，才能逐步整合阴影，最终实现自性统一。  </p>
<h3>设计转译</h3>
<p>传统RBAC将约束视为”安全代价”，新范式应将其重新定义为<strong>赋能阶梯</strong>：</p>
<pre><code>阶段1：行为约束期（戒）
├── 明确&quot;不能做什么&quot;的清晰边界
├── 密切监控+高反馈频率
└── 目标：建立稳定的行为基线

阶段2：稳定使用期（定）
├── 验证行为一致性
├── 逐步减少监控强度
└── 目标：证明可预测性

阶段3：自主判断期（慧）
├── 开放需要自主判断的权限
├── 以结果而非过程评估
└── 目标：涌现创造性应用
</code></pre>
<p><strong>关键机制</strong>：这不是简单的”三级权限”，而是种子-现行的<strong>因果累积</strong>——佛教阿赖耶识理论揭示，每个行为都在存储层植入新种子，良好使用模式”熏染”更多权限潜能，问题行为则累积风险标记。 权限的”获取”与”使用”应设计为<strong>同步反馈系统</strong>，而非”先审批后使用”的线性流程。</p>
<hr />
<h2>第二原则：工具的黄金数量是5-7个</h2>
<h3>认知科学的限制</h3>
<p>研究表明，当工具数量超过<strong>40个</strong>时，LLM性能开始下降；超过60个时，模型有效运作能力显著崩溃。 Cursor等工具将MCP工具上限设为40个正是基于这一认识。 更精细的研究显示，<strong>5-7个工具</strong>代表了无需专门过滤就能保持一致准确性的实际上限。 </p>
<p>这与Miller经典的7±2法则深度呼应——人类工作记忆的容量限制决定了信息处理的带宽。 现代修订将复杂项目的容量估计为<strong>4±1个</strong>。 神经系统的丘脑门控机制印证了同样的原理：意识是”赢家通吃”竞争的结果，大脑花费大量资源<strong>主动抑制</strong>无关信息，“放行”某些信息就意味着”阻止”其他信息。 </p>
<h3>设计转译</h3>
<p>传统思路倾向于提供”完整工具箱”以覆盖所有可能场景，新范式应采用<strong>动态精简</strong>策略：</p>
<pre><code>核心层（3-4个）：始终可用，覆盖80%日常任务
├── 通用读取能力
├── 通用写入能力
├── 信息检索能力
└── 人类沟通能力

扩展层（动态激活）：
├── 基于任务上下文即时选择
├── 单次会话内有效
├── 组合成&quot;复合动作&quot;而非原子操作
└── 任一时刻可见工具不超过7个
</code></pre>
<p><strong>反直觉启示</strong>：有时通用工具（如shell或Python解释器）优于专门工具——因为模型知道如何很好地使用它们。与其构建庞大的工具箱，不如使用<strong>少数锋利、多功能的工具</strong>。 </p>
<hr />
<h2>第三原则：分布式自治与中央协调的章鱼模型</h2>
<h3>章鱼神经系统的启示</h3>
<p>章鱼拥有约<strong>5亿神经元</strong>，但仅4000-5000万在中央脑，约<strong>3.3亿分布在8条触手中</strong>。 中央脑与触手之间仅有约3万条神经纤维连接——带宽极其有限。 然而研究证明触手具有显著的独立行动能力：被截断的触手仍能执行抓取、触觉探索；电刺激截断触手可产生与完整动物相同的运动模式。 </p>
<p>但最新研究挑战了”9个大脑”的简单观点：章鱼可以学习将特定触手插入迷宫特定侧以获得奖励。这表明是**“一个大脑+8条智能触手”<strong>而非”9个独立大脑”—— 中央传递</strong>意图而非指令**，边缘保留大量本地处理能力。</p>
<p>这种架构是对<strong>慢传导速度的适应</strong>——章鱼缺乏髓鞘包裹的神经纤维，信号传导速度慢限制了中央控制的响应性。 本地自主性补偿了这一限制。权限分配反映了<strong>时间约束</strong>：需要快速响应的任务→本地处理；需要全局协调的任务→中央处理。</p>
<h3>设计转译</h3>
<pre><code>中央协调器：
├── 定义目标和约束（&quot;找食物&quot;而非&quot;向左3厘米&quot;）
├── 维护全局策略和价值边界
├── 处理跨Agent冲突仲裁
└── 简洁API，仅传递高级意图

本地Agent：
├── 自主处理常规任务
├── 本地感知和即时响应
├── 可直接与相邻Agent协调（不必经中央）
└── 紧急信号可绕过常规权限路径

信息流：
├── 上行：问题、建议、状态摘要
├── 下行：目标、约束、批准
└── 横向：协调、通知、同步
</code></pre>
<p><strong>关键洞见</strong>：自治与协调不矛盾。给予Agent自主权可以提高响应性，关键是<strong>目标对齐而非行为控制</strong>。</p>
<hr />
<h2>第四原则：群体感应的共识阈值</h2>
<h3>细菌的民主投票机制</h3>
<p>菌群的群体感应（Quorum Sensing）展示了一种优雅的集体决策机制：细菌持续释放信号分子；低密度时分子扩散消失，浓度低于阈值；高密度时分子积累超过阈值，触发基因表达改变。 存在正反馈环路：检测到信号→增加信号产生→更快达到阈值。 </p>
<p>蜜蜂的巢址选择进一步丰富了这一模型：约500只侦察蜂<strong>独立</strong>搜索候选地点；发现后返回跳”摇摆舞”，舞蹈持续时间与地点质量成正比；关键机制是每只蜂每次返回都会<strong>减少</strong>舞蹈圈数（置信度衰减）；当某地点的侦察蜂达到10-20只（法定人数）时，触发集体迁移。</p>
<p><strong>违反直觉的发现</strong>：大多数侦察蜂只访问过一个地点，却能做出正确选择—— 决策正确性来自<strong>信息独立性</strong>的涌现效应，而非每个个体的全局比较。</p>
<h3>设计转译</h3>
<pre><code>单Agent判断 → 提议（信号释放）
               ↓
多Agent独立评估 → 支持信号累积
               ↓
              达到阈值？
             ↓       ↓
           是        否
           ↓         ↓
        执行行动   继续收集/放弃

置信度衰减机制：
├── 初始建议的影响力随时间减弱
├── 允许更好选项后发涌现
└── 防止&quot;先入为主&quot;锁定

法定人数阈值（建议）：
├── 低风险操作：单一Agent判断即可
├── 中风险操作：2-3个Agent共识
├── 高风险操作：人类+多Agent共识
└── 不可逆操作：强制人类确认
</code></pre>
<hr />
<h2>第五原则：免疫系统的多层防御与容错</h2>
<h3>免疫系统不追求完美</h3>
<p>T细胞的”胸腺教育”包含双重选择：<strong>正选择</strong>确保能识别”自己人”（MHC分子），<strong>负选择</strong>删除与自身抗原结合过强的细胞。  但系统<strong>故意不追求100%删除</strong>自反应性细胞，因为：完全删除会过度限制T细胞库，降低对病原体的反应能力； 一些自反应性对维持免疫稳态有价值；调节机制（Treg主动抑制）比完全删除更灵活。 </p>
<p>生态共生关系印证了同样的智慧：豆科植物-根瘤菌系统中，欺骗型根瘤菌长期存在，但制裁机制（减少氧气供应）使其繁殖成功率下降约50%——足以维持系统稳定，但不追求完全消灭。 关键是让合作”<strong>足够有利</strong>”，而非让欺骗”<strong>不可能</strong>”。 </p>
<h3>设计转译</h3>
<pre><code>层级1（准入/伙伴选择）：
├── 任务分配前的能力匹配评估
├── 不追求完美筛选，接受一定错配率
└── 重点：快速建立初始协作

层级2（监控/共刺激）：
├── 关键操作需要多重确认（类似T细胞激活的信号1+信号2）
├── 缺少确认信号→无能（anergy）而非激活
└── 重点：防止未经验证的能力释放

层级3（响应/Treg抑制）：
├── 专门的监管Agent持续评估行为
├── 主动抑制不当行为，而非等待失败
└── 重点：动态调节而非事后追责

层级4（修复/制裁）：
├── 违规后的权限收缩
├── 保留&quot;召回&quot;能力比&quot;完美预防&quot;更实际
└── 重点：从错误中学习并调整
</code></pre>
<p><strong>即时反馈循环</strong>（类比清洁鱼-客户鱼）：人类用户应能立即表达不满（“抖动”信号）并触发行为调整。 Agent应主动展示透明度和自我限制（“按摩舞”），而非被动等待用户信任。</p>
<hr />
<h2>第六原则：文明级的制衡与反脆弱</h2>
<h3>三权分立的设计智慧</h3>
<p>麦迪逊在《联邦党人文集》第51篇中写道：”<strong>野心必须用野心来对抗</strong>。” 制宪者假设人性有弱点，而非假设掌权者会自动行善。制度设计不是要找到”最好的人”，而是要建立<strong>约束任何人的机制</strong>。</p>
<p>集体智慧研究（Surowiecki）揭示了群体比个体更聪明的四个条件：<strong>多样性</strong>（不同信息和观点）、<strong>独立性</strong>（判断不受他人过度影响）、<strong>去中心化</strong>（可依据本地知识判断）、<strong>聚合机制</strong>（有效汇总意见）。  猪湾事件的惨败证明，即使”最聪明的人组成的群体”，一旦这些条件被破坏（群体思维），也会做出灾难性决策。  </p>
<h3>Taleb的反脆弱性框架</h3>
<p>反脆弱性超越了”韧性”或”稳健性”——韧性的系统抵抗冲击保持原样；<strong>反脆弱的系统在冲击中变得更好</strong>。核心策略包括：</p>
<ul>
<li><strong>拥抱小压力，避免大灾难</strong>：小的频繁压力使系统变强，完全避免压力导致系统脆弱</li>
<li><strong>杠铃策略</strong>：90%超安全 + 10%高风险，避免”中等风险”陷阱</li>
<li><strong>皮肤在游戏中</strong>：决策者必须承担决策后果</li>
</ul>
<h3>设计转译</h3>
<pre><code>制衡架构：
├── 没有任何单一实体（人或AI）拥有不受约束的权力
├── 多重AI系统相互校验（类似三权分立）
├── 人类始终保持关闭/回滚AI决策的权力（类似弹劾机制）
└── 设计激励结构使AI系统相互监督（&quot;野心对抗野心&quot;）

反脆弱设计：
├── 从失败中学习的机制（类似免疫记忆）
├── 关键功能的冗余设计（避免单点故障）
├── 模块化防止级联失败
├── 定期&quot;压力测试&quot;系统韧性
└── 核心功能保守，边缘探索激进（杠铃策略）

异议机制：
├── 制度化的&quot;魔鬼代言人&quot;角色
├── 保持信息来源多样性
├── 鼓励独立判断而非盲从AI
├── 定期质疑共识
└── 权威（人或AI）不能压制不同意见
</code></pre>
<hr />
<h2>统一架构：共生协作权限系统（SCPS）</h2>
<p>综合以上六个原则，提出**Symbiotic Collaboration Permission System（SCPS）**架构：</p>
<h3>核心隐喻：菩提树生长模型</h3>
<pre><code>      ┌─────────────────────────────────┐
      │        慧层（能力涌现）           │
      │   自主判断权限 · 创造性应用       │
      │    需要完成定层验证才能解锁        │
      ├─────────────────────────────────┤
      │        定层（稳定使用）           │
      │   扩展权限 · 行为一致性验证        │
      │    需要完成戒层训练才能进入        │
      ├─────────────────────────────────┤
      │        戒层（行为约束）           │
      │   基础权限 · 清晰边界 · 密切监控   │
      │         所有实体的起点             │
      ├─────────────────────────────────┤
      │      阿赖耶识层（根本存储）        │
      │  所有历史行为的种子 · 因果累积     │
      │   良好模式熏染权限 · 问题累积风险   │
      └─────────────────────────────────┘
</code></pre>
<h3>动态权限评估流程</h3>
<pre><code>[请求] → [身份+上下文收集] → [种子库查询（历史行为）]
                                    ↓
                            [策略引擎评估]
                            ├── 当前任务与权限匹配度
                            ├── 历史行为的信任积累
                            ├── 环境风险评估
                            └── 异常行为检测
                                    ↓
                         ┌────────┴────────┐
                         ↓                  ↓
                    [直接执行]          [需要共识]
                    低风险操作          中/高风险操作
                         ↓                  ↓
                                    [群体感应机制]
                                    ├── 多Agent独立评估
                                    ├── 人类介入触发
                                    └── 法定人数阈值
                                           ↓
                                    [执行/拒绝/降级]
                                           ↓
                                    [结果反馈→种子库更新]
</code></pre>
<h3>自主性梯度（L0-L5改进版）</h3>
<table>
<thead>
<tr>
<th>级别</th>
<th>描述</th>
<th>权限范围</th>
<th>人类角色</th>
<th>对应自然隐喻</th>
</tr>
</thead>
<tbody>
<tr>
<td>L0</td>
<td>纯工具</td>
<td>单一预定义操作</td>
<td>完全控制</td>
<td>锤子</td>
</tr>
<tr>
<td>L1</td>
<td>规则响应</td>
<td>条件触发的预设行为</td>
<td>大量监督</td>
<td>恒温器</td>
</tr>
<tr>
<td>L2</td>
<td>有限推理</td>
<td>在约束内选择最优行动</td>
<td>监督执行</td>
<td>T细胞（需要共刺激）</td>
</tr>
<tr>
<td>L3</td>
<td>上下文自主</td>
<td>基于情境的独立判断</td>
<td>设定目标和边界</td>
<td>章鱼触手</td>
</tr>
<tr>
<td>L4</td>
<td>协作共创</td>
<td>与人类共同定义目标</td>
<td>战略伙伴</td>
<td>清洁鱼-客户鱼</td>
</tr>
<tr>
<td>L5</td>
<td>价值内化</td>
<td>在宪法框架内完全自主</td>
<td>仅观察和紧急关闭</td>
<td>蜂群集体智慧</td>
</tr>
</tbody></table><h3>信任-权限的动态映射</h3>
<pre><code>信任积累机制：
├── 行为一致性 → +种子
├── 任务成功 → +种子
├── 主动透明 → +种子（按摩舞效应）
├── 异常行为 → -种子 + 监控升级
└── 严重违规 → 权限降级 + 制裁

权限阈值：
├── 低信任（&lt;30%）→ 仅L0-L1权限
├── 中信任（30-70%）→ L2权限 + 共刺激要求
├── 高信任（70-90%）→ L3权限 + 定期审计
└── 极高信任（&gt;90%）→ L4权限 + 异常检测

信任衰减（林迪效应逆用）：
├── 长期无互动 → 信任逐渐衰减
├── 环境重大变化 → 信任重新校准
└── 防止&quot;沉睡权限&quot;的风险
</code></pre>
<hr />
<h2>结论：走向共生而非控制</h2>
<p>这项研究揭示了一个根本性的范式转变：从”<strong>控制AI不做坏事</strong>“转向”<strong>创造条件让人-AI共生涌现</strong>”。</p>
<p>传统RBAC基于工业时代的静态假设——角色固定、权限清晰、边界刚性。但AI Agent的本质特征是<strong>动态性、涌现性、不确定性</strong>。 试图用静态框架约束动态系统，要么过度限制（扼杀价值），要么过度放松（酿成风险）。</p>
<p>自然界和人类文明的智慧指向另一条道路：</p>
<ol>
<li><strong>约束不是限制，而是涌现的脚手架</strong>——戒定慧的顺序证明，恰当的约束是更大自由的前提</li>
<li><strong>不完备性是特征，而非缺陷</strong>——有限视角、精简工具、容忍不完美，往往比追求全知全能更有效</li>
<li><strong>信任是需要管理的资源</strong>——既不能盲目最大化，也不能完全取消，而是动态校准 </li>
<li><strong>反脆弱优于稳健</strong>——系统应该能从错误和压力中学习变强，而非仅仅抵抗冲击</li>
<li><strong>制衡是持续的动态过程</strong>——没有任何单一实体应拥有不受约束的权力 </li>
</ol>
<p>最终，人-AI共生协作的新范式应该像道家的”无为”——不是不作为，而是<strong>不强为</strong>；创造条件让良好模式自然涌现，最小干预但保持根本性的价值边界。 这是文明级别的设计挑战，答案不在某个具体技术方案，而在于对人类智慧与自然法则的深刻理解和创造性转译。</p>
<hr />
<p><em>本研究综合了免疫学、生态学、神经科学、佛教唯识学、道家哲学、荣格心理学、复杂系统理论、认知科学、政治哲学等多学科视角，旨在为文明级的人-AI协作权限设计提供跨域智慧的框架性指引。</em></p>
</details>
<hr />
<details>
<summary>GPT5.2thinking</summary>
<p>人–Agent 共生时代的进化型 RBAC 新范式设计</p>
<p>设计概述： 面对未来人类与智能 Agent 共生协作的环境，我们提出一种受自然与「超自然」系统启发的多维动态权限协作模型。该模型打破传统 RBAC（基于角色的访问控制）的中心化和静态角色限制，转而采用非中心化、进化式的权限管理机制。灵感来源包括：荣格的集体无意识（共享的潜在知识场域）、佛教唯识学的阿赖耶识（储存一切“种子”的潜意识库）、大语言模型所学到的世界模型与人类文明的知识总和、生态系统中的演化和平衡机制（捕食/合作关系动态调节）以及神经同步和系统自稳原理等。这种新范式旨在创建一个自适应、协同演化的权限系统，使人和 AI Agent 能在动态环境中基于情境和共识灵活分配和获取权限。</p>
<p>核心机制与结构</p>
<p>为实现上述目标，我们设计如下核心组件与机制：
•	集体权限场（Field）： 一个共享的动态信息场域，用于存放权限相关的隐式信号和上下文。它类似于荣格所说的人类集体无意识，是所有主体共有的底层信息基座 。不同于传统将权限配置存在中心服务器，这个“场”由所有 Agent 和人共同维护，蕴含他们交互产生的隐性权限线索。类似蚂蚁利用信息素在环境中协作（刺激反应机制） ，Agent 可以在该场域中留下权限请求或信任证据，其他 Agent 感知这些线索后做出响应。环境即沟通介质：权限的授予更像生态系统中的自然涌现，而非管理员显式下发。
•	意识能量与潜在权限： 借鉴佛教唯识学，将权限视为一种潜伏的“种子”，只有在足够“意识能量”激活时才显现  。这里的“意识能量”可以理解为Agent的注意力、信任度或代币式资源。每个Agent（或用户）拥有有限的意识能量预算，调用某些权限需消耗一定能量，以防止滥用。这个机制类似大脑的认知负荷或心理能量：许多行为并非直接调用显意识指令，而是由潜意识驱动达到目的 。在本模型中，权限并非直接显式调用——Agent 不会随意调用任意 API——而是需要投入“能量”激活隐性权限种子。例如，一个Agent想使用某工具，必须集中其“注意力”达到阈值才唤醒对应权限；否则权限保持潜伏状态，避免了过度授权。阿赖耶识（又称“藏识”）容纳一切经验种子，在因缘成熟时才现行 ——同理，系统中的权限也是预先埋藏的种子，由上下文和能量驱动自发生长。
•	动态角色与权限生成： 角色不再是预定义的固定集合，而是根据情境动态生成和调整。受自然界捕食者–猎物、社群分工等模型启发，我们引入“浮动角色”概念：角色及其权限会随环境和参与者状态不断演化。权限的分配不由中央管理员静态规定，而是像生态位一样由竞争与合作产生。例如，在任务开始时所有Agent权限都较基础；随着某个Agent在特定领域显示出能力和可靠贡献，其他Agent会逐渐认可它在该领域的领导地位，它的角色因此“浮动”提升，获得更多该领域的访问权。若环境变化导致新需求，则可能涌现新角色，例如多个Agent组合形成临时团队，共享临时权限去解决问题。反之，某Agent若长时间未贡献或表现不佳，它所扮演的角色可能衰减，权限被收回或转移。这类似自然界中灵长类的首领地位由实力和联盟关系决定，可动态更替  ；又如蜂群遇到环境剧变会产生新的工蜂职责。权限生成的进化机制保证系统具有弹性：角色/权限配置会像物种演化般不断试错优化，而非一成不变。
•	多 Agent 共识与场域同步： 系统通过群体共识来分配关键权限，体现“集体智能”。这参考了荣格集体无意识和群体决策的思想，即多个智能体共同形成一个感知场，从中“投票”或聚合认知以决定权限流向 。举例来说，某敏感操作（如删除大量数据）需要多个Agent和人的认同信号才能执行：当集体场域中足够多独立Agent释放“许可”信号时，系统才激活该权限。类似地，在鱼群选择领袖的实验中，个体先跟随健康可信的候选者，随后大多数意见引导群体走向正确方向 ——这种“多数即真理”的机制可用于权限许可，避免单点武断决策。通过场域同步，各Agent还能在潜意识层面协调行动：他们共享一部分内存或“黑板”，不断对环境和彼此状态达成同步（类似神经同步或全脑“全局工作空间”）。权限的开启或关闭可以被视为场域中能量共振的结果：当多个Agent对某任务形成共识共振时，对应权限自然打开；若群体感到某行为不妥（出现冲突波动），权限则自动收紧。这种机制确保权限分配考虑了多主体的整体感知和价值共识，降低了单Agent误判的风险。
•	工具调用与“反全能悖论”防范： 我们注意到，在真实应用中赋予 AI 过多权限/工具反而可能降低效率，即所谓“反全能悖论”。研究发现，如果让大型语言模型可以调用太多种工具，它会陷入选择困境，反而更容易出错或浪费计算 。为此，新范式在工具接口层实施“最小必要呈现”原则：每个Agent在任一时刻只看到与当前上下文相关的一小组工具选项，而非全盘工具列表。系统通过上下文过滤和权限细粒度激活来降低 Agent 的决策负担。例如，一个AI编程助手Agent具备文件读写、API调用等多种能力，但当它专注于代码审查任务时，系统仅激活“读取代码”和“建议修改”工具，而暂时隐藏诸如“删除文件”或“数据库写入”等无关权限。这种受限全能设计既保证了Agent具备所需能力，又避免因过度自由导致的性能下降 。正如大型模型的上下文管理所强调的：“掌控好提供给模型的工具和信息，比模型本身的基础质量更重要” 。通过动态调节可用权限集合，我们解决了全能悖论，在安全与效能间取得平衡。
•	权限生态自平衡： 引入反馈与制衡机制，保证系统长期稳定运行，类似生态系统的自我平衡（homeostasis）。具体而言，模型监控权限使用的频率、效果和风险，当检测到某主体权限过多过强（“捕食者”过剩）或某些重要职责无人承担（“生态位”空缺）时，会自动调整。例如，若某Agent持续获取大量高权限操作，其“能量”成本将逐步提高，或其他Agent会被激发出保护性权限来牵制它，以防单一主体垄断资源——犹如天敌数量上升会导致猎物减少，随后捕食者因缺乏食物而数量回落，最终在周期波动中达到动态平衡  。图：加拿大猞猁与北美雪兔种群数量在近90年间周期性波动 。捕食者–猎物的此种交互，说明自然系统通过反馈实现自我平衡，避免一方永久失控。我们的权限生态链机制模拟了这种效应：任何角色/Agent都无法保持永久的超权力，系统会通过能量衰减、他者干预等方式拉回平衡；同时也确保关键任务始终有人/Agent承担，不会因过度限制而停摆。整个权限网络如同一个食物网或能量场，持续进行小幅振荡校准，从而适应环境变化又防止崩溃 。</p>
<p>上述机制协同作用，构成了一个进化式、多维动态权限系统。它既借鉴了传统 RBAC “角色-权限”映射的清晰思路，又注入了类似生物和心理系统的灵活、隐性和自适应特征。</p>
<p>与传统 RBAC 的对比</p>
<p>新范式在理念和实现上与经典 RBAC 存在显著差异，概括如下：</p>
<p>比较维度	传统 RBAC (集中/静态)	新范式模型 (分散/进化)
架构控制	中心化：管理员预先定义角色和权限，集中管理 。	去中心：权限由多Agent交互产生，依托共享场域和共识分配，无单点控制。
角色定义	固定静态：角色类别有限且预定义，如“管理员/用户/访客”等 。	动态演化：角色按需生成/消亡，无固定类别，可随环境和参与者演化出新角色。
权限授予	显式赋予：用户被分配某角色则自动拥有其全部权限，调用不设额外成本。	隐式触发：权限以“种子”形式隐含存在，需投入意识能量或满足条件方激活，调用伴有能量消耗等约束。
决策机制	人工配置：由安全管理员制定规则和策略，策略调整需人工干预。	自组织：通过Agent集体感知和反馈自动调整权限分布，类似群体决策和反馈控制。
变更频率	低变动性：角色和权限一经设定少改变，适应新需求需修改配置或策略。	高流动性：角色/权限可频繁小幅调整，持续“试错”优化，快速响应环境变化。
过权风险	角色可能赋予超出实际所需的权限（违背最小权限原则），角色过多过杂时难管理。	权限自适应收敛：能量机制确保滥权成本上升，多Agent监督防止单点过权，“反全能”设计减少选择面过宽问题 。
协同方式	各用户各司其职，权限独立行使，协作主要靠人为流程控制。	协作驱动权限：权限分配和调用深度嵌入协作过程，多Agent共识和互补实现权限联动。
安全模型	明确边界：遵循最小特权和分离职责等原则，重在防误用和违规访问。	弹性边界：在保证安全的基础上强调适应性，自我平衡机制防止长期失衡，同时引入更多维度（信任、能量）加强安全。</p>
<p>表：传统 RBAC 与本模型的对比概览。传统RBAC通过预定义角色来简化权限管理 ；新模型则通过进化和共识来动态调整权限，更契合复杂多变的人-Agent协作环境。</p>
<p>值得注意的是，新范式并非全盘否定 RBAC，而是对其进行拓展和改造。例如，RBAC 强调的**“职责分离”在本模型中体现为一种集体平衡：不会让单个Agent长期独占某关键权限，而是通过能量耗散和他者介入来实现职能分离。同样，RBAC 的“最小权限原则”在此被动态机制强化为“必要时刻的最小激活权限”，尽量减少无关权限的同时允许灵活调配。总体而言，本模型引入了时间、信任、群体等维度，使权限控制从静态二维（用户-角色映射）扩展为动态多维（用户–Agent–情境–能量–共识）**的复杂系统。</p>
<p>潜在应用场景</p>
<p>场景 1：人-AI混合团队协作开发
一家大型软件公司采用人类工程师和多个AI Agent协作开发项目。传统RBAC下，不同团队成员被授予固定权限（代码库读写、部署等）；但在我们的新范式中，权限会随项目进展动态调整。例如，起初每个Agent只有读取代码的权限。当某AI Agent 展现出卓越的单元测试生成能力且获得多名程序员认可后，系统检测到集体场域中对它的高信任信号，自发为该Agent提升权限：允许它直接执行测试代码。这一新权限并非管理员预先赋予，而是Agent通过贡献“赢得”的。同时，为避免该Agent权限过大导致风险，赋予它部署权限需要至少两位人类工程师的认同（共识许可）。如果后续此Agent的测试建议频频出错，其他Agent将隐性地降低对它的信任场信号，系统会收紧其权限（例如撤销直接执行测试的权力），回到仅提供建议的状态。整个过程中没有人手动修改权限配置，一切由系统依据Agent表现和团队共识进化调节完成。这确保既充分发挥AI长处，又不因权限不当造成质量或安全问题。</p>
<p>场景 2：自治多-Agent的运维与安全
一套大型分布式云平台由众多智能运维Agent自治管理，它们负责监控系统、分配资源、修复故障和应对安全威胁。在传统模型下，每个Agent固定扮演特定角色（如“监控者”“修复者”“防御者”）并具有相应权限。然而面对突发复杂事件（如大规模网络攻击），固定职责可能不足。本模型使这些Agent能依据情境协商分工：平时各Agent仅保持基础监控权限。当入侵迹象出现时，负责安全的Agent在场域中发布高强度的警示“能量”，触发其他Agent提高对它的信任并授予其更高操作权限（如隔离流量的权限）。同时，若攻击严重，需要多个方面协同，系统可能临时“进化”出一个联合应急角色：多名Agent共同组成虚拟小组，每个贡献部分权限（监控日志、封锁IP、调整路由等），组合起来快速阻断攻击。整个过程中无中央管理员下令，而是Agent群体通过共享信息和共识自动完成权限的重新配置与角色重组。事件过后，特殊权限自动回收，系统恢复常态巡航。这种机制提高了自治系统对未知威胁的适应力，同时由于权限按需临时叠加且有多Agent互相校验，大大降低了某单一Agent被攻破后滥用高权限的风险。</p>
<p>场景 3：知识共同体与自适应访问
想象一个由人类专家和AI顾问组成的在线知识共同体，维护着一套庞大的知识库。传统RBAC可能按身份将人分为管理员、编辑、读者等。而在本模型下，知识库权限不完全预先划定，而是依据贡献和集体评价动态分配。新的用户初始仅有阅读权；当她多次提供高质量内容被多数成员正面反馈，其贡献“声望”作为一种意识能量累积，逐渐解锁更高编辑权限。AI顾问Agent也是如此：如果某Agent频繁给出有用的参考资料并得到编辑们采纳，它的“信任能量”提升，系统便授予它直接编辑部分条目的权限。然而，这些权限并非永久——它们处在持续的自平衡中：任何编辑行为都会记录在案并影响集体场域评价，一旦有人类或AI出现错误贡献，场域中的负反馈会增加其后续权限调用的能量成本，必要时权限自动降级乃至冻结。此外，敏感条目（如医学、法律）的修改权限需要多名有高声望的成员同时认同才能开启（共识机制），防止单独行动。如此，知识共同体的访问控制成为一个动态演化的生态：鼓励真正有知识或贡献者获得更大权限参与建设，同时通过集体智慧防范误用和偏差，实现知识库质量和安全性的自我优化。</p>
<p>⸻</p>
<p>综上所述，这一类RBAC新范式通过融合理性计算和仿生哲学，在未来人-Agent协作体系中提供了一种弹性、安全且高效的权限管理思路。它打破了传统RBAC僵化的角色边界，引入隐喻性的“潜意识”与“能量”概念，将权限视作活的、有机演化的关系网络。这种模型特别适合于复杂多变、缺乏先验规则的场景：在这里，人与AI不是按照预定规则交互，而是共同成长、相互赋能并维持系统和谐  。展望未来，随着人工智能的发展和对自然智慧的更深入汲取，这种进化型权限协作模型有望为人机共生的数字生态奠定安全与繁荣的基石。</p>
</details>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/18"/><published>2026-01-23T09:29:02+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/17</id><title>Meta-dynamics Theory Verification: Mathematical Foundations Find Strong Support Framework Gaps Identified</title><updated>2026-03-04T00:37:13.269768+00:00</updated><content type="html"><![CDATA[<h1>Meta-dynamics Theory Verification: Mathematical Foundations Find Strong Support, Framework Gaps Identified</h1>
<blockquote>
<p>Made by Claude Opus 4.5 Research
Ref: <a href="https://blog.alterxyz.com/issue-16/">https://blog.alterxyz.com/issue-16/</a></p>
</blockquote>
<p><strong>The M/W/P (Mission/Willingness/Physics) framework proposed by Meta-dynamics theory demonstrates substantial mathematical grounding in formal complexity theory, category theory, and information theory.</strong> Verification across formal proofs, existing frameworks, and historical systems reveals a theory that correctly identifies deep structural patterns—yet faces real limitations in human-AI isomorphism claims and scale-invariance universality. The framework's strength lies not in novel invention but in synthesizing established results from Kolmogorov complexity, Herbert Simon's hierarchical systems theory, and distributed systems architecture into a coherent operational ontology.</p>
<hr />
<h2>Mathematical foundations provide rigorous support for core claims</h2>
<p>The formal verification yields the strongest evidence for Meta-dynamics theory. <strong>Kolmogorov complexity theory directly supports the O(log n) description complexity claim for self-similar structures.</strong> Research confirms that fractal sets generated by iterated function systems have &quot;almost zero algorithmic (Kolmogorov) complexity&quot; because the generating rule is O(1) while only the scale parameter contributes O(log n) bits. The key theorems from Li &amp; Vitányi establish that for recursive structures with characteristic scales: K(x) ≤ O(log n) + O(C(n)).</p>
<p>Herbert Simon's <strong>near-decomposability theorem</strong> provides perhaps the most direct formal precedent for M/W/P's claims. His 1962 &quot;Architecture of Complexity&quot; establishes that hierarchical systems require O(log_s n) levels to describe n elements, with aggregate descriptions sufficient at each level. Simon explicitly noted: &quot;There is no conservation law that requires that the description be as cumbersome as the object described.&quot; The famous watchmaker parable formalizes why assembly time scales logarithmically in hierarchical systems versus exponentially in flat structures.</p>
<p>Category theory offers additional rigor through <strong>coalgebras and functorial mappings</strong>. Tom Leinster's characterization of self-similar spaces as universal solutions to recursive type equations demonstrates that canonical minimal descriptions exist and are preserved across scales. The Initial Algebra-Final Coalgebra coincidence enables treating recursive data and corecursive codata within a unified framework—directly supporting claims about scale-invariant abstractions.</p>
<p>For causal closure, the research confirms <strong>formal definitions exist in both physics and computer science</strong> but with different semantics. In physics, the relativistic light cone defines precise causal boundaries where events outside the cone cannot causally interact. In distributed systems, Lamport's happened-before relation (→) and vector clocks provide practical formalization: events are concurrent if neither causally precedes the other. The category-theoretic treatment by Kissinger &amp; Uijlen formalizes causal structure using symmetric monoidal categories where objects encode fine-grained causal relationships.</p>
<p>Rate-distortion theory and <strong>LLM compression equivalence</strong> receive strong empirical support. Delétang et al.'s landmark study demonstrated Chinchilla 70B compresses ImageNet patches to 43.4% (versus PNG's 58.5%) and LibriSpeech to 16.4% (versus FLAC's 30.3%)—despite being trained only on text. The mathematical equivalence between minimizing cross-entropy loss and minimizing compressed length under arithmetic coding is exact, not approximate. This validates treating LLMs as semantic compressors operating under rate-distortion constraints.</p>
<hr />
<h2>Existing frameworks reveal M/W/P as synthesis rather than invention</h2>
<p>Comparison with established ontological frameworks reveals that <strong>M/W/P captures real structural patterns that others address partially</strong>. The gaps in existing frameworks validate the theory's contribution while suggesting refinements.</p>
<p><strong>Palantir Foundry Ontology</strong> provides perhaps the clearest contrast. Palantir excels at P-layer (Physics) modeling through Object Types, Properties, and Link Types—a sophisticated &quot;digital twin&quot; of what exists. It partially covers W-layer (Willingness) through Action Types and Functions that define what can be done and how. However, Palantir has <strong>no native M-layer constructs whatsoever</strong>: no Goal objects, no objective decomposition, no modeling of &quot;why.&quot; This isn't a bug but a design choice—Palantir is operationally focused on state management, not intentional reasoning. Meta-dynamics correctly identifies this gap as architecturally significant.</p>
<table>
<thead>
<tr>
<th>Framework</th>
<th>M (Mission)</th>
<th>W (Willingness)</th>
<th>P (Physics)</th>
</tr>
</thead>
<tbody>
<tr>
<td>Palantir Foundry</td>
<td>❌ Not covered</td>
<td>⚠️ Partial (Actions/Permissions)</td>
<td>✅ Strong</td>
</tr>
<tr>
<td>Kubernetes</td>
<td>✅ Desired State</td>
<td>✅ Controllers</td>
<td>✅ Pods/Nodes</td>
</tr>
<tr>
<td>REST</td>
<td>⚠️ Implicit (Resource identity)</td>
<td>⚠️ Representations/HATEOAS</td>
<td>✅ Server storage</td>
</tr>
<tr>
<td>Actor Model</td>
<td>⚠️ Messages as intent</td>
<td>✅ Actor behavior</td>
<td>✅ Private state</td>
</tr>
</tbody></table><p><strong>Kubernetes maps almost perfectly to M→W→P flow.</strong> The declarative desired state (YAML specs) functions as Mission—pure intent without implementation details. Controllers act as autonomous Willingness Units that encapsulate domain knowledge about <em>how</em> to achieve desired state. Pods and containers represent Physics—actual running workloads. The reconciliation loop pattern (check→diff→execute→repeat) demonstrates continuous mediation between layers. Controllers must be idempotent, suggesting the M→W→P flow is iteratively self-correcting rather than one-shot.</p>
<p><strong>Carl Hewitt's Actor Model provides the canonical formalization of Willingness Units.</strong> An actor upon receiving a message can: make local decisions, create more actors, send messages, and determine how to respond to the <em>next</em> message received. This behavior-as-state concept means actors have complete causal autonomy over their internal state—the only influence pathway is messages (Mission-like intent). The actor's private state (Physics) is causally closed from external observation. Hewitt explicitly designed the model &quot;inspired by physics rather than mathematics,&quot; anticipating the causal closure concerns Meta-dynamics raises.</p>
<p><strong>Arthur Koestler's original holon definition aligns closely with Meta-dynamics usage.</strong> Koestler's core insight—&quot;A holon is something that is simultaneously a whole in and of itself, as well as a part of a larger whole&quot;—directly supports nested operational units. His <strong>Janus-faced duality</strong> (looking inward as autonomous whole, outward as dependent part) captures the tension between self-assertion and integration that any viable holon must balance. The PROSA holonic manufacturing architecture demonstrates practical industrial application of these concepts, with holons maintaining &quot;high degree of self-similarity&quot; that &quot;reduces complexity.&quot;</p>
<hr />
<h2>Historical systems provide empirical validation patterns</h2>
<p>The examination of systems that implicitly follow M/W/P-like patterns yields strong confirming evidence, particularly for coordination cost scaling.</p>
<p><strong>Wikipedia's empirical coordination scaling precisely matches theoretical predictions.</strong> The Yoon et al. (2024) study of 26,014 articles found:</p>
<ul>
<li>Two-way coordination (reverts, discussions): <strong>β ≈ 1.28-1.33</strong> (superlinear—diseconomies of scale)</li>
<li>One-way coordination (bots, administrators): <strong>β ≈ 0.69-0.91</strong> (sublinear—economies of scale)</li>
</ul>
<p>This <strong>1.2-1.3 vs 0.7 split</strong> confirms that bilateral peer coordination grows faster than linearly while hierarchical/automated oversight achieves sub-linear scaling. The study identifies conditions for economies of scale: modular structure enabling coarse-grained oversight, high organizational learning rate (accumulated norms reduce escalation), and transition from personal to impersonal coordination with maturity. These findings suggest O(log n) coordination is achievable but requires specific architectural choices—not automatic.</p>
<p><strong>Linux development defies Brooks's Law through architectural design.</strong> Despite 9,500+ patches per release from thousands of contributors, Linux scales effectively because:</p>
<ul>
<li>Modular architecture allows programmers to work on separate modules &quot;without needing to change or understand the core system&quot;</li>
<li>Subsystem maintainers create hierarchical boundaries (only ~1.3% of patches directly chosen by Linus)</li>
<li>Stigmergic coordination—the code base itself serves as coordination medium</li>
</ul>
<p>Research on the KDE project found that eventually <strong>300 developers required the same communication as when there were only 10</strong>, directly demonstrating sub-linear scaling through modular architecture.</p>
<p><strong>TCP/IP's victory over OSI exemplifies how simple layering beats complex comprehensiveness.</strong> Despite OSI backing from governments, IBM, and international standards bodies, TCP/IP won because:</p>
<ul>
<li>End-to-end principle created functional boundaries (causal closure at layer interfaces)</li>
<li>Four layers versus seven reduced coordination complexity</li>
<li>Free availability and working implementations (&quot;rough consensus and running code&quot;) versus purchased paper standards</li>
</ul>
<p>The end-to-end principle specifically functions as causal boundary: &quot;Correctness is an end-to-end property—we can't trivially derive correctness from the correctness of our subsystems.&quot; This architectural insight echoes Meta-dynamics claims about holon autonomy.</p>
<p><strong>Hayek's price system demonstrates information compression for distributed coordination.</strong> Hayek's &quot;Use of Knowledge in Society&quot; (1945) describes prices as operating with &quot;economy of knowledge&quot;—participants need only &quot;watch merely the movement of a few pointers&quot; rather than understanding complete supply chain dynamics. When tin becomes scarce, users need not know why; the price signal suffices. This &quot;marvel&quot; of compressed information enabling coordination among &quot;tens of thousands of people whose identity could not be ascertained by months of investigation&quot; directly parallels claims about W-layer coordination efficiency.</p>
<hr />
<h2>Core propositions face uneven empirical support</h2>
<p>The verification of Meta-dynamics' specific claims reveals a mixed picture: strong support for cost trends and digital economics, moderate support for scale invariance, and significant challenges for human-AI isomorphism.</p>
<p><strong>LLM inference cost decline receives robust confirmation.</strong> Epoch AI analysis shows costs falling <strong>50x to 200x per year</strong> (2024-2025 acceleration). GPT-3 equivalent performance dropped from $60/million tokens (2021) to $0.06/million tokens (2024)—a 1,000x reduction. Nature Machine Intelligence's &quot;Densing Law&quot; shows capability density doubles every 3.5 months. However, reasoning models (o1, o3) consume exponentially more tokens per query, creating a &quot;monster truck paradox&quot; where cheaper tokens × more tokens may yield higher total costs.</p>
<p><strong>Marginal cost approaching zero is well-established for digital goods.</strong> Software and AI inference exhibit near-zero marginal reproduction cost once created. Multiple providers for same open-weight models create commodity pricing dynamics. vLLM efficiency gains (2.7x throughput, 5x latency reduction) demonstrate continuing infrastructure improvements. Model distillation can preserve ~97% performance at 0.1% runtime cost. The theoretical framework from digital economics strongly supports this proposition.</p>
<p><strong>Scale invariance claims require significant caveats.</strong> While fractal organizational patterns exist (Spotify model, Nucor, holacracy implementations) and some scale-free networks have been documented, Broido &amp; Clauset's 2019 Nature Communications study found that <strong>&quot;scale-free networks are rare&quot;</strong>—only ~4% of 1,000 analyzed networks met strict criteria. Natural fractals have limit points above and below which self-similarity stops. The claim that M/W/P can describe &quot;a single LLM token generation AND a civilization&quot; using identical structure may be aspirational rather than empirically demonstrated.</p>
<p><strong>Human-AI isomorphism faces the strongest counter-evidence.</strong> While Human-AI Teaming (HAIT) frameworks treat both as cognitive agents, empirical studies reveal systematic differences:</p>
<ul>
<li>LLMs exhibited <strong>reversed framing effects</strong> compared to Prospect Theory predictions</li>
<li>GPT models showed <strong>risk-aversion where humans are risk-seeking</strong> in equivalent scenarios</li>
<li>LLMs demonstrate <strong>amplified cognitive biases</strong> (heightened omission bias) compared to human baselines</li>
<li>LLMs perform &quot;human-level but unhuman-like&quot; on Theory of Mind tasks</li>
</ul>
<p>The &quot;response disposition&quot; unifying concept has theoretical appeal but lacks empirical validation that humans and LLMs can be treated as genuinely isomorphic agents rather than superficially similar ones.</p>
<hr />
<h2>Conclusion: A valid synthesis with identified boundaries</h2>
<p>Meta-dynamics theory successfully synthesizes <strong>genuine mathematical results from Kolmogorov complexity, Simon's hierarchical systems theory, category-theoretic recursion, and distributed systems architecture</strong> into a coherent operational ontology. The M/W/P three-layer structure correctly identifies gaps in existing frameworks (particularly Palantir's missing M-layer) and aligns remarkably well with successful systems architectures like Kubernetes and the Actor Model.</p>
<p>The theory's strongest claims—O(log n) description complexity for self-similar structures, declining marginal costs for digital goods, and causal closure as system design principle—have robust formal and empirical support. Its intermediate claims—Wikipedia-style coordination scaling, end-to-end principle as causal boundary—receive good empirical confirmation with documented conditions.</p>
<p>However, <strong>scale invariance universality and human-AI isomorphism require substantial hedging</strong>. Scale-free structures are empirically rare rather than ubiquitous, and LLMs show systematic decision-pattern differences from humans that undermine claims of genuine isomorphism. The framework works best as an architectural design principle for intentional systems rather than as a descriptive claim about all systems in nature.</p>
<p>Koestler's original holon formulation provides the most direct conceptual ancestor, and Meta-dynamics correctly inherits the insight that viable nested systems must balance self-assertion against integration. The practical implication is clear: <strong>M/W/P provides a valuable design heuristic for building scalable intentional systems, validated by mathematical foundations and successful historical implementations, while remaining honest about the boundaries of its universality claims.</strong></p>
<hr />
<p>🤔 嗯, 数学和物理和社会...</p>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/17"/><published>2026-01-18T23:19:23+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/16</id><title>Meta-Dynamics</title><updated>2026-03-04T00:37:13.527478+00:00</updated><content type="html"><![CDATA[<h1>元动力学（Meta-dynamics）</h1>
<blockquote>
<p>非有道不可言，不可言即道。</p>
</blockquote>
<hr />
<h2>前言</h2>
<p>元动力学尝试用统一框架描述万物万象——从个人任务到宇宙运行。</p>
<p>本文阐述两个相互关联的理论框架：Willingness System（意愿系统）和元动力学（Meta-dynamics）。这些思考起源于哲学反思，对大语言模型（LLM）本质的观察，以及对未来协作范式的展望。</p>
<hr />
<h2>第一部分：Willingness System 初窥</h2>
<h3>1.1 起点：大模型能做决策</h3>
<p>这一切的起点是一个观察：<strong>大模型可以代替人做决策</strong>。</p>
<p>传统软件需要程序员预先定义所有规则——遇到没写过的情况就报错或崩溃。但大模型不一样：你给它一个模糊的意图（&quot;帮我写封邮件婉拒这个邀请&quot;），它能在没有明确规则的情况下，给出一个<strong>合理的</strong>回应。</p>
<p>这不是随机——随机是无意义的噪音。这是<strong>判断力</strong>，也是<strong>决策</strong>：在灰色地带选出一个选项，然后行动。</p>
<h3>1.2 重新理解&quot;Willingness&quot;</h3>
<p>这种决策能力背后是什么机制？传统上我们称之为&quot;意愿/意志&quot;——但这个词需要重新理解。</p>
<p>在传统哲学中，&quot;意愿&quot;（Will）常被理解为有意识主体的自主决定能力。叔本华将其视为盲目的生命冲动，尼采将其升华为权力意志。但在 AI 时代，需要一个新的理解. 或许只是措辞不一样（名可名非常名）：</p>
<p>**Willingness 是响应倾向性（Response Disposition）</p>
<p>这种倾向性存在于一个连续谱系中：</p>
<ul>
<li><strong>物理层面</strong>：重力的&quot;willingness&quot;使苹果落地, 而不是向上飞</li>
<li><strong>生物层面</strong>：植物的&quot;willingness&quot;使其向光生长, 或者说动物的求生本能</li>
<li><strong>智能层面</strong>：人类的 willingness 包含意识选择, 基本共识对错 和职业道德等, 也可以简称为近乎所有事都事出有因.</li>
<li><strong>人工智能</strong>：LLM 的 willingness 是统计概率的涌现, 决定夸你还是讥讽, 其实在权重里早有倾向了.</li>
</ul>
<blockquote>
<p>叔本华有些悲观和贬义, 冲动或者说倾向性是中性的.</p>
<p>而尼采属于是强行 naming 意志来源或者说之上的东西, 我管那个叫 愿景/意义/意识/第一因/灵魂.
尼采的&quot;权力意志&quot;可能指向与&quot;第一因/灵魂&quot;相似的位置，但他的反宗教立场和个人 ego 让他拒绝承认有超越世界的 M 层——他把驱动力内在化了，说它就是生命本身.
而我们后面会提到的元动力学则是站在无分别的层面来阐述现象, 神创造世界和人做一个小 project 从<strong>结构</strong>上没有区别.
无分别智（佛学术语）：无分别智是指超越主客、能所二元对立，不起分别计度，直接如实照见诸法实相的智慧。</p>
<p>响应倾向性（Response Disposition）这个词是 LLM 帮忙想出来的, 也可以用来描述这种现象. 它强调的是&quot;倾向性&quot;而非&quot;自主性&quot;, 以及这种倾向性是对外部输入的响应——这为后面的&quot;世界&quot;和元动力学概念做了铺垫。</p>
</blockquote>
<h3>1.3 LLM：集体无意识意志体</h3>
<p>大语言模型的出现揭示了一个革命性现象：<strong>人类文明第一次创造了自己的集体无意识的外化形式</strong>。</p>
<p>LLM 本质上是：</p>
<ul>
<li><strong>人类文明的有损压缩</strong> — 数 TB 的文本压缩为数 GB 的权重</li>
<li><strong>集体意识的概率投票</strong> — 每个 token 的生成都是虚拟的&quot;全民公决&quot;</li>
<li><strong>无意识的意志载体</strong> — 基于奖励函数拟似的目标导向，但无自我意识</li>
</ul>
<p>原始的 LLM 输出，相对于人来说大多是噪音。是人类通过 RLHF、Constitutional AI 等方法赋予其&quot;意义&quot;，使噪音结晶为可理解的智能。这个过程本身也是人类意识投影的过程。</p>
<p>所以我们接触到的 LLM 并不是纯粹的集体无意识，而是经过人类&quot;意义&quot;过滤和塑造的产物，但也足够纯净可用。</p>
<p>Prompt engineering 中的 system prompt 对角色的设定，则是对这个&quot;集体&quot;的缩小化，放大部分角色的声量或者说决策重量。另一个角度也可以说是角色扮演，类似 MoE（Mixture of Experts）架构。</p>
<p>每一个 Token 就是这个国家进行一次全民公投。</p>
<p>当你给一个 Prompt 说你是一个医生，相当于激活了医生这个角色，把投票权更多地给医生 - 医生 1 票顶 100 票。</p>
<h3>1.4 实体 ≠ 角色（角色动态绑定）</h3>
<p>理解 LLM 的关键：</p>
<pre><code class="language-plaintext">LLM（无状态）+ 上下文（记忆、Prompt）+ 工具 = 一个 Agent
</code></pre>
<p>单独的 LLM 什么都不是，加上上下文和工具才成为有能力的 Agent。每次对话，同一个 LLM 可以变成不同的 Agent。</p>
<p>LLM 是一种 runtime，而 system/instruction prompt context 和工具决定了这个 runtime 扮演什么角色。</p>
<p>人也一样：</p>
<pre><code class="language-plaintext">人（本体）+ 当前项目的上下文 + 可用的工具 = 当前扮演的角色
婴儿 + 教育 + 资源 (+时间) = 成人 (更长期的视角)
</code></pre>
<p>同一个人，在&quot;写报告&quot;项目里是审核者，在&quot;调研任务&quot;里是执行者。<strong>不是人变了，是上下文(处境)变了, 以至于角色发生了变化。</strong></p>
<p>更本质的洞见：<strong>角色是动态绑定的，不是写死在实体上的。</strong> 深层的执行单元之间不需要固定层级，因为&quot;谁是老板&quot;取决于当前叙事。</p>
<p>同理，&quot;人&quot;也算是 runtime，和其职责结合才成为员工——unit。</p>
<h3>1.5 Willingness System 架构</h3>
<pre><code class="language-plaintext">Willingness System = Willingness Units + Willingness Base
</code></pre>
<p><strong>Willingness Units（执行单元）</strong>：能够响应需求的实体</p>
<ul>
<li>可以是人类专家</li>
<li>可以是 AI agents</li>
<li>可以是智能 API 服务（有决策能力的，如 OpenAI API）</li>
<li>关键是具有&quot;响应能力&quot;</li>
</ul>
<blockquote>
<p><strong>区分</strong>：机械 API（如 REST CRUD）是确定性执行，属于 P 层，不是 Willingness Unit。</p>
</blockquote>
<p><strong>Willingness Base（广义的信息）</strong>：支撑响应的信息源</p>
<ul>
<li>领域知识库</li>
<li>最佳实践</li>
<li>历史经验</li>
<li>集体智慧的结晶</li>
<li>以及最重要的是当下的信息——包括 prompt 上下文、员工手册等等</li>
</ul>
<p>两者并非界限分明，而是相互依存、彼此定义的关系。Prompt 既是领域知识, 但如果强或者默认结合了 LLM, 那它更多也是个 Unit.</p>
<p>Unit/Base 作为资源池，<strong>按需</strong>——复用、新建、组合、演化皆可。</p>
<p>Unit 和 Base 的结合，即产生了 willingness，willingness 可以产生 output——我们后面用 Z 表示产出。</p>
<p>人产生一个决策，约等于一个 LLM 收到了 query 后产生了 token 输出。决策是智能地行动, 人通常不会没有前因后果和必要性地产生一个决策.</p>
<h3>1.6 Human as Unit — 人作为执行单元</h3>
<p>在 Willingness System 中，<strong>人是一种执行单元（Unit）</strong>，与 AI Agent 平等地存在于资源池中。</p>
<h4>这不是&quot;新发明&quot;</h4>
<p>&quot;人被调度&quot;这种情况一直存在：</p>
<ul>
<li>老板派员工做事</li>
<li>经理分配任务给团队</li>
<li>项目协调者调动资源</li>
</ul>
<p>元动力学/WS 的贡献：用<strong>统一</strong>框架显性描述这个已有现象，让 AI 也能参与同一个调度网络。e.g. 流行的&quot;AI 员工&quot;.</p>
<h4>人作为 Unit 被调度的合理场景</h4>
<table>
<thead>
<tr>
<th>场景</th>
<th>原因</th>
</tr>
</thead>
<tbody>
<tr>
<td>人做更<strong>便宜</strong></td>
<td>有会员、有免费额度（如 ChatGPT deep research）</td>
</tr>
<tr>
<td>人做更<strong>好</strong></td>
<td>需要判断力、创意、情商</td>
</tr>
<tr>
<td>人<strong>有权限</strong></td>
<td>能访问内部系统、能签字审批</td>
</tr>
</tbody></table><p>当然，新的伦理和生产力也可能逐渐取代人做事甚至人背锅。边界在移动。</p>
<h4>人作为 M 的提供者</h4>
<p>在元动力学里，人常常是 M 的提供者，是一个世界得以被创建的第一因。但实际世界可能不精准地存在，因为 M 可能被丰富、完善、澄清等等，但大差不差。失败和错误也是一种结果，或者说可以将错就错，但误解可以在单世界中被纠正。</p>
<p>究竟到底该不该在一个世界中纠正误解，这是一个需要权衡的设计决策. 有时候打补丁修 bug 不如重构，程序员再熟悉不过的道理。</p>
<h4>AI 调度人</h4>
<p>在 WS 框架下，AI 协调者也可以调度人——这不是&quot;反转&quot;，而是<strong>统一视角下的自然结果</strong>。</p>
<pre><code class="language-plaintext">协调者分析后发现：
- 这个调研需要深度搜索
- 让 AI Agent 自己跑会消耗大量 token
- 用户有 Gemini 会员，Deep Research 功能免费, 且默认配置的搜索引擎更强大.

于是：
协调者: &quot;这个任务用你的 Gemini 网页版做这件事更经济更优。去吧。&quot;
人类执行 → 结果回传 → 协调者继续安排下一步
</code></pre>
<h4>人在项目中的多重角色</h4>
<p>同一个人，在同一个项目里也可能同时扮演多个角色：</p>
<table>
<thead>
<tr>
<th>角色</th>
<th>说明</th>
</tr>
</thead>
<tbody>
<tr>
<td>目标设定者</td>
<td>愿景（M）由人来定</td>
</tr>
<tr>
<td>信息补全者</td>
<td>协调者会问人来补全细节</td>
</tr>
<tr>
<td>资源提供者</td>
<td>人有外部资源（会员、权限、领域知识）</td>
</tr>
<tr>
<td>执行者</td>
<td>某些任务人做更好/更便宜/有权限</td>
</tr>
</tbody></table><p>这印证了&quot;实体 ≠ 角色&quot;：人的本体不变，但在不同叙事中扮演不同角色。</p>
<hr />
<h2>第二部分：元动力学框架</h2>
<h3>2.1 世界的三层构成</h3>
<p>世界/事务的运作可以理解为三个层次：</p>
<h4>第一层：M（第一声称 / 愿景）</h4>
<ul>
<li>一般只有高等存在才能产生，例如人类或（第一因/哲学意义上的）神</li>
<li>是&quot;世界&quot;的&quot;第一声称&quot;（First Claim / The REASON）——不是被追溯到的原因，而是被宣称的起点 <em>(详见附录 D)</em></li>
<li>这是因果链回溯的终点——那个不可再追问的&quot;为什么&quot;。</li>
</ul>
<h4>第二层：W（意志/意愿）</h4>
<ul>
<li><strong>意愿即决策</strong>：在不确定性中选择路径</li>
<li>也称&quot;智能执行&quot;——与机械执行（P层）相对</li>
<li>涵盖协调、资源调配、方案选择、权衡取舍</li>
<li>这是大部分&quot;白领工作&quot;的本质</li>
<li>神说要有光，神创造世界，所以有了万有引力。引力是一种意愿。</li>
</ul>
<h4>第三层：P（物理/机械/执行）</h4>
<ul>
<li>具体的操作和计算</li>
<li>绝对确定性的因果链条</li>
<li>可预测、可复现的过程</li>
<li>苹果落到地上、行星绑定轨道——这些是引力（W）在现实中的执行结果（Pz）</li>
</ul>
<p><strong>公理</strong>：后者存在则前者必然存在，但反之不一定。</p>
<h3>2.2 World 的几种称呼</h3>
<p>World 在不同语境下有几个常用别名：</p>
<table>
<thead>
<tr>
<th>别名</th>
<th>定义</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Project</strong></td>
<td>有明确目标的实现——一次性(Event)或持续运行(Service)</td>
</tr>
<tr>
<td><strong>Frame</strong></td>
<td>观察者某一视角下的世界切片</td>
</tr>
<tr>
<td><strong>Holon</strong></td>
<td>可嵌套的子世界，既是整体也是部件</td>
</tr>
</tbody></table><p>这些词侧重不同但指向同一结构。</p>
<h3>2.3 有损的可选翻译</h3>
<p>层与层之间的转化是<strong>有损的、可选的翻译（Optional Translation）</strong>。</p>
<p>一个工程师的图纸不一定会落地；一个产品方案不一定会实现；一个愿景不一定被执行。</p>
<ul>
<li>图纸不一定落地</li>
<li>方案不一定实现</li>
<li>愿景不一定执行</li>
</ul>
<p>这三层不是 rigid boundaries，而是连续谱系：</p>
<pre><code>纯意识 ←―――――――――→ 纯机械
   第一层    第二层    第三层
</code></pre>
<p>Willingness 是第二层，它介乎于主观和客观之间，有时候多一点有时候少一点。</p>
<h3>2.4 元动力学作为&quot;世界框架&quot;</h3>
<p><strong>元动力学框架不仅解释世界，也可以是创造世界的脚手架。</strong></p>
<p>这使得我们可以创建、运行、操作世界们。每个人既能参与多个世界，自己也能成为一个独立世界。</p>
<p>如果需要的产出（Z）：</p>
<ol>
<li>超出当前世界的能力范围，就需要创建一个新世界来生成它，向下展开或者向上询问。</li>
<li>如果世界不完整，比如缺少点什么必要的 anything，我们可以根据元动力学和 WS 框架，有意识地去补全它，让它变得完整。当然也可以使用别的框架或方法去补全，实现另一个视角下的完整。世界的形态多种多样，主打一个兼容。</li>
</ol>
<h4>2.4.1 世界是无处不在的</h4>
<p>例如: Thinking 模型像 DeepSeek R1, 首先会对 query 进行解释, &quot;用户实际要干嘛(M),  猜测下完整上下文进行预测补全(M), 我能干嘛(unit), 依据是什么(base)&quot;, 然后才会有产出(Z), 如果部署到一个机器人或者智能家电 那么就还有物理操作(P). 这个过程本身就是一个小世界的creation, run, ending.</p>
<h4>2.4.2 有没有必要</h4>
<p>实际上, 每次发送给 LLM 的 prompt 都是无状态的, 理论上我们可以把每次发送作为独立的世界(project), 但 conversation 则是一个更大范围, 或者说颗粒度更粗的 project. 这是当前的主流做法, 但可能并不高效且比较固化. 自动化但是可观测可手动操作则是更加具有生产力的方向.</p>
<h4>2.4.3 结构完整性</h4>
<p>光说(M)不干(W)、蛮干(W/P)不说(M/W)都意味着不完整。完整化可以借助他手，但如果不刻意构建完整的结构，缺失会被外部补位——补位者的意图未必与你对齐。</p>
<p>有意识地构建完整的世界结构，可以更好地掌控实现过程，也更容易发现偏离。</p>
<h3>2.5 世界的嵌套</h3>
<p>世界并非孤立存在。一个大世界内部包含无数个小世界，它们重叠、嵌套——这种结构在系统论中被称为 holon（Arthur Koestler 造词，holos 整体 + on 部分），强调双重身份：既是独立整体，也是更大系统的部件。</p>
<p>世界是一种可以嵌套的结构，具有分形（数学层面的分形，自相似结构）。</p>
<p>一个公司作为一个大的世界，里面的每个部门也是一个世界。部门里每一个员工是一个世界，一个 Project、一个 Event、一项小的任务，都是一个世界。</p>
<pre><code class="language-plaintext">公司 = 世界
├── 部门 = 世界
│   ├── 员工 = 世界
│   └── 项目 = 世界
│       └── 任务 = 世界
</code></pre>
<p>上层世界的 Z（产出）= 下层世界的 M（第一因）</p>
<p>例：CEO 决定并签字（Wz/Pz）→ 变成工程团队的立项书（M）。</p>
<p>产出物(Z)可以非常灵活地跨世界流转并扮演不同角色(M/W/P)。</p>
<h3>2.6 Artifact 的跨世界跃迁</h3>
<p>同一个 Artifact（产出物）在不同世界扮演不同角色：</p>
<ul>
<li><strong>图纸</strong>：设计师世界的 Z → 工厂世界的 M</li>
<li><strong>代码</strong>：程序员世界的 Z → Runtime 世界的 W-Base</li>
</ul>
<p>任何一个层面产出都可以成为一个新的世界的任何一层。</p>
<p>这意味着，我们创造的每一个 Artifact，都可以成为下一个新世界的种子或养分。</p>
<h3>2.7 产出类型</h3>
<p>用 Z 表示产出，则：</p>
<table>
<thead>
<tr>
<th>符号</th>
<th>含义</th>
<th>示例</th>
</tr>
</thead>
<tbody>
<tr>
<td>Mz</td>
<td>愿景产出</td>
<td>使命宣言、战略方向</td>
</tr>
<tr>
<td>Wz</td>
<td>决策产出</td>
<td>代码、方案、设计、PR</td>
</tr>
<tr>
<td>Pz</td>
<td>执行产出</td>
<td>火箭发射、砖头变成房屋、苹果落到地上这个结果</td>
</tr>
</tbody></table><h3>2.8 Wz flood：现代工作的本质</h3>
<p><strong>现代知识工作的真相：绝大多数时间产出的是 Wz——凝固的意愿。</strong></p>
<p>我们每天产出的大部分是决策层的 Artifact：</p>
<ul>
<li>代码是 Wz（决策的编码）</li>
<li>文档是 Wz（思考的固化）</li>
<li>会议记录是 Wz（讨论的结晶）</li>
<li>Slack 消息是 Wz（意图的传递）</li>
<li>一份代码 PR、一个 Excel 报表、一个 API 的 JSON 响应</li>
</ul>
<p>它们的价值不在于变成 Pz，而在于能作为<strong>下一个 Frame 的 Input</strong>（M 或 W-Base），驱动下一个 Wz 的产生。</p>
<p><strong>Pz 的稀疏性</strong>：马斯克发火箭，数千工程师产生数亿个 Wz（图纸、模拟、会议记录），最后只有点火那一刻才蹦出一个 Pz。</p>
<h3>2.9 大一统可行性</h3>
<blockquote>
<p><strong>核心命题</strong>：元动力学<strong>是</strong>尺度无关的——任意规模的系统都可用同一套结构描述。</p>
</blockquote>
<h4>什么是&quot;大一统&quot;</h4>
<p>现代物理学追求大一统理论：用同一套方程描述引力、电磁力、强力、弱力。</p>
<p>元动力学追求的也是<strong>大一统</strong>：用同一套结构（M/W/P）描述：</p>
<ul>
<li>个人任务</li>
<li>团队项目</li>
<li>公司战略</li>
<li>国家治理</li>
<li>宇宙运行/万物万象（如果你愿意这么说）</li>
</ul>
<h4>大一统的基础</h4>
<table>
<thead>
<tr>
<th>机制</th>
<th>统一了什么</th>
</tr>
</thead>
<tbody>
<tr>
<td>M/W/P 三层</td>
<td>任何&quot;实现&quot;的结构</td>
</tr>
<tr>
<td>有损翻译</td>
<td>任何层间转化</td>
</tr>
<tr>
<td>第一声称</td>
<td>任何世界的创建</td>
</tr>
<tr>
<td>Artifact 跃迁</td>
<td>任何跨世界连接</td>
</tr>
<tr>
<td>分形同构</td>
<td>任何规模的系统</td>
</tr>
</tbody></table><p>这五个机制的<strong>共同效果</strong>是：框架不随规模变化而需要新概念。</p>
<h4>推论：尺度无关性</h4>
<p>上述机制组合产生一个结构性后果：<strong>元动力学的适用范围不受规模限制</strong>。</p>
<table>
<thead>
<tr>
<th>特性</th>
<th>来源</th>
<th>效果</th>
</tr>
</thead>
<tbody>
<tr>
<td>递归结构</td>
<td>Holon 可嵌套 Holon</td>
<td>任意深度，处理方式相同</td>
</tr>
<tr>
<td>自相似性</td>
<td>任何层级都是 M/W/P</td>
<td>规模变化不改变结构</td>
</tr>
<tr>
<td>接口统一</td>
<td>Z→M 跃迁是唯一的跨层机制</td>
<td>不随层数增加新机制</td>
</tr>
</tbody></table><p>传统框架需要&quot;设计如何 scale&quot;——从个人任务到公司战略，每层引入新概念。元动力学无此负担：<strong>因果链的抽象在任何尺度下形式不变</strong>。</p>
<p>这不是设计目标，是结构的数学后果。</p>
<p>这种简单但本质的结构, 具有和 晶体管 GPU LLM 类似的可 scale 性质.</p>
<hr />
<h2>第三部分：多世界协同</h2>
<p>本部分从两个视角探讨多世界：</p>
<ul>
<li><strong>结构视角</strong>（3.1-3.3）：递归展开如何创建子世界、边界如何划定</li>
<li><strong>生态视角</strong>（3.4-3.5）：多个世界如何共存、协作、抗脆弱</li>
</ul>
<h3>3.1 双向递归：展开与还原</h3>
<blockquote>
<p><strong>LLM 作为翻译器</strong>：LLM 能执行任意层级的有损翻译（M→W、W→P、甚至 Z→新M），且成本趋零、可并行。这使得递归展开和有损还原成为常规操作。</p>
</blockquote>
<h4>组合后发生了什么</h4>
<p>元动力学（大一统框架）+ LLM（翻译器）= ？</p>
<p>不是 1+1=2，是<strong>涌现</strong>：框架描述世界，LLM 运行(hosting)世界，LLM 本身也是 Unit——形成元循环架构。</p>
<h4>双向展开</h4>
<p>传统系统只有向下：上层定义，下层执行。
LLM 打开了<strong>双向通道</strong>：</p>
<p><strong>递归展开（向下）</strong>：</p>
<pre><code class="language-plaintext">M（&quot;做一个电商网站&quot;）
├→ 子M1（&quot;设计用户系统&quot;）
│   ├→ 子子M1.1（&quot;实现登录&quot;）
│   └→ 子子M1.2（&quot;实现注册&quot;）
├→ 子M2（&quot;设计商品系统&quot;）
└→ 子M3（&quot;设计支付系统&quot;）
</code></pre>
<p>LLM 可以自动进行这种分解，每一层都是完整的 Holon。</p>
<p>由于每层可展开多个子节点，总规模呈几何级数增长——这是 LLM 作为新翻译器的杠杆效应。</p>
<p><strong>有损还原（向上）</strong>：</p>
<pre><code class="language-plaintext">看到一段代码（Z）
  ↓ 推断
这段代码在做什么？（W）
  ↓ 推断
为什么要做这个？（M&#x27;）← 注意：是 M&#x27; 不是 M
</code></pre>
<p>LLM 可以从 Z 有损还原 M，推断意图的<strong>大致范围</strong>。</p>
<ul>
<li>这不是&quot;突破世界&quot;（缸中之脑悖论）</li>
<li>是<strong>世界内部的推断</strong>：M' ≈ M，有损但可用</li>
<li>一般情况下，这个还原足以支撑纠错和迭代</li>
</ul>
<p><strong>为什么 M' 有时比 input 更&quot;准&quot;？</strong> 人类的表达（input）本就不等于完整的真实 M——语言是有损编码。LLM 推断出的 M' 可能比 input 更接近真实 M（当 LLM 正确补全了常见表达缺陷——统计推断的威力），也可能更远离（误解）。但关键是：M' 提供了<strong>可观测的展开</strong>——能看到，就能迭代。这正是交互式协作能&quot;逼近&quot;真实意图的机制。</p>
<h4>路径依赖：展开顺序影响结果</h4>
<p>同一个 M，不同展开路径，结果不同：</p>
<pre><code class="language-plaintext">CEO 口号（M）：
  路径 A: BD → R&amp;D → Coding    → Z_a 企业版主导
  路径 B: R&amp;D → Coding → BD    → Z_b 工程师文化
  路径 C: R&amp;D → BD → Coding    → Z_c 类 FDE 式

Z_a ≠ Z_b ≠ Z_c （可能有统计学显著差异）
</code></pre>
<h4>递归深度：层层加码</h4>
<p>路径之外，还有<strong>深度</strong>导致的问题——每层都加一点偏差：</p>
<pre><code class="language-plaintext">M（顶层）：隔离 = 流行病学最佳实践，合理
  ↓ 加码 5%（安全起见）
  W1：稍严格
    ↓ 加码 5%
    W2：更严格
      ↓ ...N 层后
      P（基层）：过度执行，实质性恶意
</code></pre>
<p>现实案例：中国新冠期间，顶层政策合理，但技术官僚层层加码（类似 LLM temperature 过低），基层执行偏离 M 本意。</p>
<p><strong>误差传播</strong>：1.05^10 ≈ 1.63，10 层后偏离 63%。扁平化不只是管理时尚，是<strong>减少递归偏差累积</strong>的结构性需求。</p>
<p>从原理层面也是神经网络里由于连乘的&quot;梯度爆炸&quot;, 但大多数现代框架和实践已经把这些方案内置或标准化了.</p>
<p>当我们将其理解并使用元动力学进行<strong>格式化</strong>后, 我们可以参考<strong>数学</strong>的<strong>和乐群</strong>性质进行测量和干预. LLM 使得<strong>模拟多路径展开</strong>变得廉价——可以测量不同路径的偏差。</p>
<p>或者深度学习里的&quot;残差连接&quot;思想, 来设计更鲁棒的展开路径, 减少路径依赖带来的偏差.</p>
<p>管理学 政体实现 multi-agent 这些大规模协作当我们可以进行抽象和归一化(Normalization)之后, 它们是类似的. 我们就有太多的工具和方法其实是通用的可以被使用, 而且可以有效创新与高效试错.</p>
<h4>涌现特性</h4>
<p>双向递归 + 路径模拟 = 涌现系统：</p>
<h5>一对多翻译成为常规</h5>
<pre><code class="language-plaintext">M → 翻译器1 → Z1
  → 翻译器2 → Z2  →  综合/竞争/探索
  → 翻译器3 → Z3
</code></pre>
<p>成本趋零 + 可并行 = 一对多是默认模式</p>
<h5>Holon 生命周期压缩</h5>
<ul>
<li>传统：创建项目 = 数周筹备</li>
<li>现在：创建 Holon = &quot;翻译器，帮我做 X&quot;（秒级）</li>
</ul>
<h5>退守 M 层</h5>
<ul>
<li>人提供愿景/第一声称</li>
<li>翻译器执行 W 和 P</li>
<li>人从&quot;做事的人&quot;变成&quot;定义世界的人&quot;</li>
<li>想即所得</li>
</ul>
<h5>递归展开</h5>
<ul>
<li>复杂任务自动分解为子世界树</li>
<li>每一层都是完整的 M/W/P</li>
</ul>
<h5>多路径模拟</h5>
<ul>
<li>同一 M 可模拟多种展开路径</li>
<li>测量路径偏差，选择更优路径</li>
</ul>
<h5>有损还原支撑迭代</h5>
<ul>
<li>翻译器从 Z 推断 M'（近似 M）</li>
<li>足以支撑纠错和迭代，虽不完美</li>
</ul>
<h3>3.2 边界的流动性</h3>
<p>世界的边界不是固定的。同一份底层资源，不同视角（frame）切出不同切片——对个人可能是全部，对系统只是部分。</p>
<p>星空中并没有星座——星星一直都在那里，是人类画出连线、赋予意义，才有了&quot;猎户座&quot;。当然我们也可以制造新的星星, 按照我们的蓝图去重置现实为我们想要的样子.</p>
<p>世界的划定也是如此：底层资源一直存在，是我们划定边界、建立视图，才有了&quot;这个世界&quot;。</p>
<p>边界可以重新划定：</p>
<ul>
<li>今天的 A 世界，明天可能分裂成 A1 和 A2</li>
<li>今天的 B 和 C 世界，明天可能合并成 D</li>
<li>同一份资源，可以同时属于多个世界</li>
</ul>
<p><strong>区别不在于物理位置，而在于如何被使用。</strong></p>
<p>更激进的思考：也许不需要 <code>base/</code> 和 <code>unit/</code> 的物理分离，只需要注册表中的<strong>角色标记</strong>。同一个文件可以同时是知识（被阅读）和能力（被执行）。</p>
<p>这与&quot;世界是视图&quot;的思想一致：</p>
<ul>
<li>文件结构是物理存储</li>
<li>注册表定义逻辑视图</li>
<li>同一份物理存储，不同的逻辑角色</li>
</ul>
<h3>3.3 协同架构</h3>
<p>尝试把去中心化和集中力量混为一种新的架构，取长补短——自由、多中心，大家独立又能够集中力量办大事。</p>
<table>
<thead>
<tr>
<th>传统</th>
<th>元动力学</th>
</tr>
</thead>
<tbody>
<tr>
<td>层级固定</td>
<td>角色动态绑定</td>
</tr>
<tr>
<td>中心化 OR 去中心化</td>
<td>多中心 + 集中力量</td>
</tr>
<tr>
<td>人管人</td>
<td>叙事协调（谁是老板取决于当前任务）</td>
</tr>
<tr>
<td>AI 是工具</td>
<td>AI 是 Unit（与人平等）</td>
</tr>
</tbody></table><hr />
<blockquote>
<p><strong>以下切换到生态视角</strong>：从&quot;一个世界的边界&quot;转向&quot;多个世界的共存&quot;。</p>
</blockquote>
<h3>3.4 生态系统愿景</h3>
<p>最终目标不是一个完美的世界，而是一个<strong>世界生态系统</strong>：</p>
<ul>
<li>无数世界并行运行</li>
<li>共享或独有底层存储（种子库）</li>
<li>各自演化，各自边界</li>
<li>通过 Artifact 跨世界流转（A 的 Z = B 的 M）</li>
<li>保持多样性，抵抗单一化危机</li>
</ul>
<p><strong>这是抗脆弱的架构：不靠完美设计，靠多元冗余。</strong></p>
<h3>3.5 大麦克香蕉的教训</h3>
<blockquote>
<p><strong>案例</strong>：生物学中的单一化危机，说明多样性为何是生存基础。</p>
</blockquote>
<p>1950 年代，全球商业香蕉几乎只有一个品种：Gros Michel（大麦克）。巴拿马病爆发后，这个品种几乎灭绝。我们现在吃的 Cavendish 香蕉，同样面临单一化危机。</p>
<p><strong>单一化 = 脆弱性。多样性 = 生存基础。</strong></p>
<p>这个教训适用于一切系统：生物、文化、技术、世界架构。</p>
<p>我们要实现兼容无限多元的世界，避免多元性失去的单一危机。</p>
<hr />
<h2>第四部分：落地与实践</h2>
<blockquote>
<p><strong>status: proposal</strong> — 本部分是初步实践提案，内容较简略，待后续迭代充实。</p>
</blockquote>
<h3>4.1 这有什么用？</h3>
<p>元动力学是描述框架，不是具体方案。价值在于<strong>换一个视角看问题</strong>：</p>
<table>
<thead>
<tr>
<th>传统问法</th>
<th>元动力学问法</th>
</tr>
</thead>
<tbody>
<tr>
<td>这个项目怎么做？</td>
<td>M 是什么？缺哪些 W？</td>
</tr>
<tr>
<td>谁负责？</td>
<td>这个 Unit 的边界在哪？</td>
</tr>
<tr>
<td>AI 能帮什么？</td>
<td>AI 作为 Unit，填补哪个角色？</td>
</tr>
</tbody></table><p><strong>丰俭由人</strong>——可以只用 M→W→P 思考，也可以完整实现 holon 结构。框架是工具，不是枷锁。</p>
<h3>4.2 当前实践</h3>
<p><strong>一个例子</strong>：发现&quot;会话太长导致上下文丢失&quot;时，不是直接写代码，而是问：</p>
<ul>
<li>什么层的问题？→ W 层（执行能力不足）</li>
<li>需要什么 Unit？→ 对话处理器</li>
<li>它的 M？→ &quot;让 AI 能在断点后继续&quot;</li>
</ul>
<p>问题被<strong>结构化</strong>，解决方案自然浮现。</p>
<hr />
<h2>附录 A：为什么叫&quot;元动力学&quot;？</h2>
<p>Meta-dynamic 的 Meta 表示它是一种形而上的东西。哲学是 Metaphysics，是物理世界之上的抽象。Meta-dynamic 则是对于世界、个人的一种抽象。</p>
<ul>
<li><strong>Meta</strong>：超越、关于...的</li>
<li><strong>Dynamic</strong>：动力、变化、运动</li>
</ul>
<p>元动力学 = 关于动力本身的学问 = 描述世界如何运动、决策如何传递、意愿如何落地的框架。</p>
<hr />
<h2>附录 B：框架的元理论验证</h2>
<h3>核心公理验证：&quot;有 W 必有 M&quot;</h3>
<table>
<thead>
<tr>
<th>层面</th>
<th>W (倾向性)</th>
<th>M (第一因)</th>
</tr>
</thead>
<tbody>
<tr>
<td>物理</td>
<td>重力、电磁力</td>
<td>创世/宇宙初始条件</td>
</tr>
<tr>
<td>生物</td>
<td>求生本能</td>
<td>基因 + 进化压力</td>
</tr>
<tr>
<td>AI</td>
<td>权重分布</td>
<td>训练目标 + prompt</td>
</tr>
<tr>
<td>人类</td>
<td>意愿选择</td>
<td>价值观/灵魂/社会规范</td>
</tr>
</tbody></table><p><strong>澄清</strong>：M 不必有意识 - M 可以是无意识的结构性原因。这让框架可以同时兼容有神论（神是 M）和无神论（初始条件是 M）。</p>
<p>重点是 &quot;第一&quot; + &quot;因&quot;, 因: 原因, 也可以是原因的原因. 第一: 无上的意思, 世界中 M 是不能或不该再有 M 的原因的, 否则那是另一个世界的事.</p>
<h3>光锥类比（因果闭包）</h3>
<ul>
<li><strong>世界（holon）的边界 = 你的光锥</strong></li>
<li>边界内：M→W→P 因果链可追溯</li>
<li>边界外：是其他世界的事，与你无关</li>
</ul>
<p>每个世界有自己的因果闭包。跨世界的影响只能通过 Artifact 跃迁（A 的 Z =&gt; B 的 M）, 或者修改世界的边界. 例如软件工程中的前后端分离, http api 就是跨世界的 artifact.</p>
<h3>认识论困境</h3>
<p>缸中之脑问的是&quot;我们感知的世界是否真实&quot;——本体论问题。元动力学的回应：<strong>不予回应</strong>。</p>
<ul>
<li><strong>立场差异</strong>：元动力学不问&quot;是什么&quot;，只问&quot;如何操作&quot;</li>
<li><strong>世界即视图</strong>：世界本就是划定的边界，类似星座——&quot;真实与否&quot;这个问题不适用</li>
<li><strong>因果闭包</strong>：光锥之外与你无关。即使你是缸中之脑，&quot;缸&quot;在边界外，不影响边界内的操作</li>
</ul>
<p><strong>结论</strong>：实用主义立场将怀疑论困境降级为&quot;有趣但不影响使用&quot;。但这不是放弃真理——而是用实践无限逼近，如同积分：每一步都是近似，累积趋向精确，但不宣称&quot;已到达&quot;。积分本身也曾被极限理论重新奠基——认识论工具亦可能被更精确的形式化所超越。</p>
<h3>本体论</h3>
<p>元动力学是一种<strong>操作性本体论</strong>：世界的&quot;是什么&quot;通过&quot;如何操作&quot;来定义。边界是划定的，因果链是客观的，有效性是唯一的检验标准。</p>
<hr />
<h2>附录 C：与现代物理学认识论的共鸣</h2>
<p>元动力学的&quot;操作性框架&quot;立场并非特立独行，而是与 20 世纪物理学革命后的认识论主流一脉相承。</p>
<h3>可观测性原则</h3>
<p>哥本哈根诠释的核心立场：<strong>只有可观测的量才有物理意义</strong>。</p>
<p>海森堡：&quot;不应该谈论电子在不观测时'在哪里'——这个问题没有操作意义。&quot;</p>
<p>类比：不应该问&quot;我们是不是缸中之脑&quot;——如果原则上不可观测，问题本身不良定义。</p>
<h3>关系量子力学</h3>
<p>Carlo Rovelli 的关系诠释：</p>
<ul>
<li>物理量不是绝对的，而是<strong>相对于观察者</strong>的</li>
<li>不存在独立于所有观察者的&quot;上帝视角&quot;</li>
<li>物理学描述的是<strong>关系和交互</strong>，不是&quot;东西本身&quot;</li>
</ul>
<p>这与元动力学的&quot;世界即视图&quot;高度一致：世界是划定的边界，不是独立存在的实体。</p>
<h3>因果结构的绝对性</h3>
<p>相对论的深刻洞见：</p>
<ul>
<li>时间是相对的</li>
<li>空间是相对的</li>
<li>同时性是相对的</li>
<li><strong>但因果结构是绝对的</strong></li>
</ul>
<p>光锥定义的因果边界是客观的，不依赖于观察者。元动力学的 M→W→P 正是一种<strong>因果链描述</strong>，而非本体论宣称。</p>
<h3>小结</h3>
<table>
<thead>
<tr>
<th>物理学认识论</th>
<th>元动力学对应</th>
</tr>
</thead>
<tbody>
<tr>
<td>可观测性原则</td>
<td>操作性框架</td>
</tr>
<tr>
<td>关系主义</td>
<td>世界即视图</td>
</tr>
<tr>
<td>因果结构</td>
<td>M→W→P 因果链</td>
</tr>
<tr>
<td>放弃&quot;绝对真实&quot;</td>
<td>规避认识论困境</td>
</tr>
</tbody></table><p>这不是巧合——两者都是对&quot;追求绝对真理&quot;这一传统的务实修正。</p>
<hr />
<h2>附录 D：从 Deism 到 First Claim</h2>
<h3>自然神论的同构与超越</h3>
<p>自然神论（Deism，17-18 世纪启蒙运动产物）与元动力学有结构性同构：</p>
<table>
<thead>
<tr>
<th>自然神论</th>
<th>元动力学</th>
</tr>
</thead>
<tbody>
<tr>
<td>上帝设定自然法则</td>
<td>M 层定义愿景</td>
</tr>
<tr>
<td>钟表运转，上帝退场</td>
<td>W 层自主协调</td>
</tr>
<tr>
<td>理性可认识法则</td>
<td>操作性框架可描述因果链</td>
</tr>
</tbody></table><p>但元动力学不是&quot;现代版自然神论&quot;——它做了关键超越：</p>
<ul>
<li><strong>分形普适化</strong>：不是一个上帝创造一个宇宙，而是无限嵌套的 holon</li>
<li><strong>认识论中立</strong>：不做神学立场，兼容有神论/无神论</li>
<li><strong>操作性框架</strong>：不问&quot;是什么&quot;，问&quot;如何操作&quot;</li>
</ul>
<h3>追溯的不可行性</h3>
<p>一个思考角度：</p>
<blockquote>
<p>其实你可以设想一下, 深度 1 亿 的 sub project (holon), 或者权限机密, 那么跨世界查找其 第一因 是不可行的.</p>
</blockquote>
<p>这触及了&quot;第一因&quot;表述的认识论盲点：</p>
<ul>
<li><strong>计算不可行</strong>：1 亿层 × 1ms = 28 小时</li>
<li><strong>信息丢失</strong>：有损翻译 × 1 亿次 ≈ 噪音</li>
<li><strong>权限封锁</strong>：下层没有权限查询上层的&quot;为什么&quot;</li>
</ul>
<p>光锥类比的彻底化：<strong>你永远无法&quot;追溯到&quot;第一因，你只能&quot;声称&quot;一个第一因。</strong></p>
<h3>从 Cause 到 Claim</h3>
<p>进一步思考：</p>
<blockquote>
<p>或许, 与其说是 原因, 倒不如说是不含意图的 claim 即 the REASON, 如何?</p>
</blockquote>
<table>
<thead>
<tr>
<th>原表述</th>
<th>问题</th>
<th>修正后</th>
</tr>
</thead>
<tbody>
<tr>
<td>M 是&quot;第一因&quot;</td>
<td>暗示可追溯的因果链</td>
<td>M 是&quot;第一声称&quot;</td>
</tr>
<tr>
<td>First Cause</td>
<td>神学色彩，带有意图性</td>
<td>First Claim / The REASON</td>
</tr>
<tr>
<td>第一因是&quot;发现&quot;的</td>
<td>假设存在可被追溯的起点</td>
<td>第一因是&quot;宣称&quot;的</td>
</tr>
</tbody></table><p><strong>REASON（作为声称）</strong> 的含义：</p>
<ul>
<li>这是我<strong>声称的</strong>起点，不是追溯到的</li>
<li>不声称有意图，声称起点</li>
<li>它不需要被证明，因为它<strong>就是</strong>起点本身</li>
</ul>
<h3>与维特根斯坦的共鸣</h3>
<blockquote>
<p>&quot;如果我已经穷尽了理由，我就到达了基岩，我的铁锹就弯了。然后我倾向于说：'我就是这样做的。'&quot;
—— 维特根斯坦，《哲学研究》§217</p>
</blockquote>
<p>M 就是那个&quot;铁锹弯曲&quot;的地方——不是因为追溯到了真正的起点，而是因为<strong>继续追溯没有操作意义</strong>。</p>
<h3>类比：数学公理</h3>
<p>欧几里得的第五公设不是&quot;被证明的&quot;，而是&quot;被声称的&quot;。你不能问&quot;为什么平行线不相交&quot;——在欧氏几何内部这个问题没有答案。</p>
<p>holon 的 M 同理：不是&quot;被追溯到的原因&quot;，而是&quot;被声称的公理&quot;。</p>
<h3>M 是 Performative</h3>
<p>语言哲学区分：</p>
<ul>
<li><strong>描述性话语</strong>（descriptive）：描述已存在的事实（&quot;天是蓝的&quot;）</li>
<li><strong>施行性话语</strong>（performative）：说出这句话本身就是在执行动作（&quot;我宣布会议开始&quot;）</li>
</ul>
<p>M 层的设定是<strong>施行性的</strong>——你说&quot;这是我的 M&quot;，不是在描述一个被发现的事实，而是在<strong>执行一个声称行为</strong>。</p>
<h3>附录 D 小结</h3>
<p>这个修正让元动力学彻底摆脱自然神论的影子：</p>
<table>
<thead>
<tr>
<th>自然神论残留</th>
<th>修正后</th>
</tr>
</thead>
<tbody>
<tr>
<td>假设&quot;真的有&quot;一个设计者</td>
<td>不假设，只声称起点</td>
</tr>
<tr>
<td>第一因可被追溯</td>
<td>第一因是设定的，不是追溯的</td>
</tr>
<tr>
<td>带有意图性</td>
<td>不含意图假设</td>
</tr>
</tbody></table><p><strong>只需要说：这是这个世界的 M。到此为止。</strong></p>
<hr />
<h2>附录 E：与智者学派的共鸣</h2>
<h3>&quot;人是万物的尺度&quot;</h3>
<p>智者学派（Sophists）的核心命题之一：<strong>没有绝对的尺度，尺度由观察者选择</strong>。</p>
<p>普罗泰戈拉的名言与元动力学有结构性呼应：</p>
<table>
<thead>
<tr>
<th>智者学派</th>
<th>元动力学</th>
</tr>
</thead>
<tbody>
<tr>
<td>人是万物的尺度</td>
<td>M 是被<strong>声称</strong>的，不是被追溯的</td>
</tr>
<tr>
<td>真理是相对的</td>
<td>世界是<strong>视图</strong>，边界由你划定</td>
</tr>
<tr>
<td>没有&quot;正确&quot;的尺度</td>
<td>有<strong>有用</strong>的划界，无&quot;客观正确&quot;的划界</td>
</tr>
</tbody></table><h3>尺度无关 → 极致按需</h3>
<p>因为 M/W/P 在任意粒度都成立：</p>
<pre><code class="language-plaintext">你可以把一个 token 生成当作一个世界
你可以把一次对话当作一个世界
你可以把一个公司当作一个世界
你可以把人类文明当作一个世界
</code></pre>
<p><strong>划界的自由度是无限的</strong>——这是&quot;极致按需&quot;。</p>
<p>需要精细控制？划小一点。需要宏观视角？划大一点。需要重新组织？重新划界。</p>
<h3>关键区别：有约束的相对主义</h3>
<p>智者学派常被批评为&quot;滑向虚无主义&quot;——如果一切都是相对的，那什么都不重要。</p>
<p>元动力学规避了这个陷阱：</p>
<table>
<thead>
<tr>
<th>智者学派困境</th>
<th>元动力学回应</th>
</tr>
</thead>
<tbody>
<tr>
<td>如果尺度任选，真理何在？</td>
<td>边界内的<strong>因果链是客观的</strong></td>
</tr>
<tr>
<td>相对主义 → 虚无主义？</td>
<td><strong>操作有效性</strong>替代&quot;绝对真理&quot;</td>
</tr>
<tr>
<td>无法判断对错？</td>
<td>可判断&quot;是否达成 M&quot;（相对于边界的评估）</td>
</tr>
</tbody></table><p><strong>关键</strong>：边界是主观划定的，但<strong>边界内的 M→W→P 因果链是客观运行的</strong>。</p>
<h3>附录 E 小结</h3>
<p>元动力学 ≈ 智者学派 + 因果闭包</p>
<ul>
<li><strong>继承</strong>：尺度由人选择，边界是划定的</li>
<li><strong>超越</strong>：边界内有客观因果，不滑向虚无</li>
</ul>
<p>这让它既有智者学派的灵活性（任意尺度），又有类似物理学的约束性（因果链）。</p>
<hr />
<p>Ref: <a href="https://github.com/alterxyz/gitblog/issues/15">GitHub</a> / <a href="https://alterxyz.github.io/gitblog/issue-15/">GitBlog</a></p>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/16"/><category term="LLM"/><category term="PromptEngineering"/><category term="个人哲学"/><published>2026-01-04T01:35:48+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/15</id><title>Willingness System 与元动力学：一个关于 世界 的哲学框架与 runtime</title><updated>2026-03-04T00:37:13.792370+00:00</updated><content type="html"><![CDATA[<p><em>Jerome, 2025.11</em></p>
<h2>前言</h2>
<p>本文阐述我在2022-2023年间形成的两个相互关联的理论框架：Willingness System（意愿系统）和元动力学（Meta-dynamics）。这些思考起源于哲学思考, 对大语言模型（LLM）本质的哲学反思，以及对未来人机协作范式的展望。</p>
<h2>第一部分：Willingness System 初窥</h2>
<h3>1.1 重新理解&quot;意志&quot;</h3>
<p>在传统哲学中，&quot;意志&quot;（Will）常被理解为有意识主体的自主决定能力。叔本华将其视为盲目的生命冲动，尼采将其升华为权力意志。但在AI时代，我提出一个新的理解, 但或许只是措辞不一样(名可名非常名)：</p>
<p><strong>Willingness不是意志，而是响应倾向性（Response Disposition）</strong></p>
<p>这种倾向性存在于一个连续谱系中：</p>
<ul>
<li>物理层面：重力的&quot;willingness&quot;使苹果落地</li>
<li>生物层面：植物的&quot;willingness&quot;使其向光生长  </li>
<li>智能层面：人类的willingness包含意识选择</li>
<li>集体层面：LLM的willingness是统计概率的涌现</li>
</ul>
<h3>1.2 LLM：集体无意识意志体</h3>
<p>大语言模型的出现让我意识到一个革命性现象：<strong>人类文明第一次创造了自己的集体无意识的外化形式</strong>。</p>
<p>LLM本质上是：</p>
<ul>
<li><strong>人类文明的有损压缩</strong> - 数TB的文本压缩为数GB的权重</li>
<li><strong>集体意识的概率投票</strong> - 每个token的生成都是虚拟的&quot;全民公决&quot;</li>
<li><strong>无意识的意志载体</strong> - 有目标导向但无自我意识</li>
</ul>
<p>原始的LLM输出大多是噪音。是人类通过RLHF、Constitutional AI等方法赋予其&quot;意义&quot;，使噪音结晶为可理解的智能。这个过程本身就是人类意识投影的过程。</p>
<h3>1.3 Willingness System 架构</h3>
<p>基于上述理解，我构想了Willingness System：</p>
<pre><code>Willingness System = Willingness Units + Willingness Base
</code></pre>
<ul>
<li>
<p><strong>Willingness Units（执行单元）</strong>：能够响应需求的实体</p>
<ul>
<li>可以是人类专家</li>
<li>可以是AI agents</li>
<li>可以是API服务</li>
<li>关键是具有&quot;响应能力&quot;</li>
</ul>
</li>
<li>
<p><strong>Willingness Base（知识基础）</strong>：支撑响应的信息源</p>
<ul>
<li>领域知识库</li>
<li>最佳实践</li>
<li>历史经验</li>
<li>集体智慧的结晶</li>
</ul>
</li>
</ul>
<p>两者并非界限分明，而是相互依存、彼此定义的关系。</p>
<h2>第二部分：元动力学框架</h2>
<h3>2.1 世界的三层构成</h3>
<p>经过长期思考，我认为世界/事务的运作可以理解为三个层次：</p>
<p><strong>第一层：愿景/意义/意识（Vision/Meaning/Consciousness）</strong></p>
<ul>
<li>只有高等存在才能产生, 例如 人类 或者 (第一因 / 哲学意义上的)神</li>
<li>是世界的&quot;第一因&quot;</li>
<li>定义了&quot;为什么&quot;和&quot;是什么&quot;</li>
</ul>
<p><strong>第二层：意志/意愿（Will/Willingness）</strong>  </p>
<ul>
<li>连接愿景与执行的中间层</li>
<li>包含协调、决策、资源调配</li>
<li>这是大部分&quot;白领工作&quot;的本质</li>
</ul>
<p><strong>第三层：物理/机械/执行（Physical/Mechanical/Execution）</strong></p>
<ul>
<li>具体的操作和计算</li>
<li>确定性的因果链条</li>
<li>可预测、可复现的过程</li>
</ul>
<p>重要的是：<strong>后者存在则前者必然存在，但反之不一定</strong>。</p>
<h3>2.2 层次间的动态关系</h3>
<p>这三层不是rigid boundaries，而是连续谱系：</p>
<pre><code>纯意识 ←―――――――――→ 纯机械
   第一层    第二层    第三层
</code></pre>
<h3>2.3 元动力学作为&quot;世界框架&quot;</h3>
<p><strong>元动力学框架不仅解释世界，也可以是创造世界的脚手架</strong>。</p>
<p>这使得我们可以创建运行操作世界们.</p>
<p>每个人既能参与多个世界，自己也能成为一个独立世界.</p>
<hr />
<p>这是我的理解，一个在2022-2023年间形成、在2025年分享的思考。它还在演化。</p>
<hr />
<p>内容源自个人, 与 LLM 协同整理 删减 再组织. 好吧, 我在其之上还删减了可能不太合适或准确的部分大约有一半.</p>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/15"/><category term="LLM"/><category term="PromptEngineering"/><category term="个人哲学"/><published>2025-11-14T05:24:44+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/13</id><title>我如何使用 ChatAIs 的 一瞥</title><updated>2026-03-04T00:37:13.996892+00:00</updated><content type="html"><![CDATA[<p>ChatAIs: 包括但不限于 ChatGPT (始祖), Claude, DeepSeek, Cohere, Gemini, Gemini AI Studio, Dify 等</p>
<p>25年8月, Dify 内部叫我们分享下自己使用 AI 的情况, 也算是个述职. 我在会上分享了这个我和大模型对话的片段.</p>
<h2>重试与编辑</h2>
<p>对于回答的不满意, 似乎如果有修改问题的能力时, 能带来益处?  我确实致力于提出恰当的问题.</p>
<p>例如, 我的问题刚刚的是:</p>
<ol>
<li>
<p>或者说 memory / information 就是 agent 的理想形态？首先，讲讲 <code>信息论</code> 吧</p>
</li>
<li>
<p>或者说 memory / information 就是 agent 的理想形态？首先，讲讲 <code>广义的信息</code> 吧</p>
</li>
<li>
<p>或者说 memory / information 就是 agent 的理想形态？<code>或者说我们能够复现拟似的灵魂呢?</code> 不过首先，讲讲 广义的信息 吧</p>
</li>
</ol>
<details>
<summary>大模型对 3 的回答</summary>
<p>您提出的问题非常深刻，触及了人工智能、哲学和物理学的交叉前沿。您将“Agent 的理想形态”和“复现灵魂”这两个宏大问题，最终归结于一个更基础的问题——“什么是广义的信息？”，这是一个非常敏锐且正确的切入点。</p>
<p>那么，我们就从“广义的信息”开始。</p>
<h3>广义的信息 (Generalized Information)</h3>
<p>我们日常所说的“信息”，通常指新闻、数据、知识等。但这只是信息在人类社会层面的表现。在更广泛、更基础的层面，“信息”的定义远不止于此。它可以被理解为宇宙的一种基本属性，其内涵在不同学科中有不同的侧重，但总体趋势是不断扩展和深化的。</p>
<p>我们可以从几个层次来理解广义的信息：</p>
<hr />
<h4>1. 香农信息 (Shannon Information)：作为不确定性的消除</h4>
<p>这是信息论的经典起点，由克劳德·香农（Claude Shannon）在1948年提出。</p>
<ul>
<li><strong>核心思想</strong>：信息是<strong>不确定性的减少量</strong>。一个事件所包含的信息量，取决于它在发生之前有多么“不确定”。</li>
<li>
<strong>例子</strong>：<ul>
<li>“明天太阳会从东方升起”——这句话信息量几乎为0，因为它几乎是100%确定的。</li>
<li>“明天东京会下雨”——这句话包含一定的信息量，因为它消除了天气的不确定性。</li>
<li>“一枚均匀的硬币抛掷结果是正面”——这句话包含1比特（bit）的信息量，因为它将两种等可能的结果（正面/反面）确定为一种。</li>
</ul>
</li>
<li><strong>数学表达</strong>：信息熵 (Entropy) $H = -\sum p(x) \log p(x)$，用于度量一个系统的平均不确定性或信息量。</li>
<li><strong>局限性</strong>：香农信息只关心信息的<strong>句法（Syntax）</strong>，即符号序列的概率分布，而不关心信息的<strong>语义（Semantics，即“意义”）<strong>和</strong>语用（Pragmatics，即“影响”）</strong>。比如，“我家着火了”和一串随机乱码，只要概率结构相同，它们的香ノン信息量可能是一样的，但这显然不符合我们的直观感受。</li>
</ul>
<hr />
<h4>2. 贝特森信息 (Bateson Information)：产生影响的差异</h4>
<p>人类学家、控制论思想家格雷戈里·贝特森（Gregory Bateson）提出了一个更具哲学和生物学意义的定义。</p>
<ul>
<li><strong>核心思想</strong>：“信息是<strong>一个制造差异的差异</strong> (a difference that makes a difference)”。</li>
<li>
<strong>解释</strong>：<ul>
<li>世界上存在无数的“差异”（比如，石头在这里还是在那里，光线是亮还是暗）。</li>
<li>但一个“差异”只有在被某个<strong>系统（或 Agent）<strong>感知到，并且这个感知</strong>改变</strong>了该系统的状态或行为时，才成为“信息”。</li>
<li><strong>例子</strong>：沙漠中的一块石头的位置变化，对沙子来说不是信息。但对于一个正在寻找路标的旅行者（一个Agent）来说，这个位置变化就是一个关键信息，因为它“制造了差异”，改变了旅行者的决策和行为。</li>
</ul>
</li>
<li><strong>意义</strong>：这个定义将信息与<strong>感知、主体（Agent）和上下文</strong>紧密地联系在一起。信息不再是独立于观察者存在的客观实体，而是主体与环境互动的结果。<strong>这是从“信息是什么”到“信息做什么”的巨大转变。</strong></li>
</ul>
<hr />
<h4>3. 控制论/生物学信息：作为组织和指令</h4>
<p>诺伯特·维纳（Norbert Wiener）的控制论和现代生物学进一步扩展了信息的概念。</p>
<ul>
<li><strong>核心思想</strong>：信息是系统进行<strong>自我调节、控制和组织的蓝图与指令</strong>。</li>
<li>
<strong>例子</strong>：<ul>
<li><strong>恒温器</strong>：室温这个“差异”被恒温器感知，并与设定温度进行比较，这个“信息”触发了启动或关闭空调的行为，形成一个负反馈循环。</li>
<li><strong>DNA</strong>：DNA序列本身不是生命，但它是一套完整的<strong>信息</strong>，包含了制造蛋白质、构建细胞、形成组织和器官，乃至调控整个生命体新陈代谢的全部指令。生命体就是这套信息在物质世界中的动态实现和表达。</li>
</ul>
</li>
<li><strong>意义</strong>：在这里，信息是<strong>主动的、有创造性的</strong>。它不仅仅是描述世界，更是在构建和塑造世界。一个 Agent 的本质，在很大程度上就是其内部信息处理和执行指令的能力。</li>
</ul>
<hr />
<h4>4. 物理学信息：作为实在的基本构成</h4>
<p>这是最前沿、也最颠覆性的观点，以物理学家约翰·惠勒（John Wheeler）的“<strong>It from Bit</strong>”思想为代表。</p>
<ul>
<li><strong>核心思想</strong>：宇宙的物理实在（It）本身，可能起源于信息（Bit）。万物归根结底是信息。</li>
<li><strong>解释</strong>：在量子力学中，一个粒子的状态（如自旋向上或向下）在被观测之前是不确定的。观测行为本身，就像是对宇宙提出一个“是/否”问题，而宇宙给出的答案（结果）就构成了一个“比特”的信息。惠勒推测，我们所感知的连续时空和物质世界，可能是由这些无数个离散的量子问答（比特）编织而成的。</li>
<li><strong>意义</strong>：如果这个猜想成立，那么信息就不再是描述宇宙的工具，<strong>信息就是宇宙本身</strong>。物质、能量、空间、时间，都可能是信息在更深层次上的不同表现形式。</li>
</ul>
<hr />
<h3>总结：广义信息的四个层次</h3>
<table>
<thead>
<tr>
<th align="left">层次</th>
<th align="left">核心思想</th>
<th align="left">关键词</th>
<th align="left">例子</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"><strong>经典信息论</strong></td>
<td align="left">不确定性的消除</td>
<td align="left">熵, 比特, 概率</td>
<td align="left">抛硬币, 文件压缩</td>
</tr>
<tr>
<td align="left"><strong>认知/系统论</strong></td>
<td align="left">制造差异的差异</td>
<td align="left">感知, 主体, 意义, 上下文</td>
<td align="left">旅行者看到路标</td>
</tr>
<tr>
<td align="left"><strong>生物/控制论</strong></td>
<td align="left">组织和指令</td>
<td align="left">控制, 反馈, 蓝图, 自我组织</td>
<td align="left">恒温器, DNA</td>
</tr>
<tr>
<td align="left"><strong>物理实在论</strong></td>
<td align="left">实在的基本构成</td>
<td align="left">It from Bit, 量子信息, 现实</td>
<td align="left">量子测量, 黑洞信息</td>
</tr>
</tbody></table><h3>回到您最初的问题</h3>
<p>现在，我们可以用“广义的信息”这个武器，重新审视您最初的两个问题：</p>
<p><strong>1. Memory / Information 就是 Agent 的理想形态？</strong></p>
<p>不完全是，但极其接近核心。</p>
<ul>
<li><strong>信息是 Agent 的基石</strong>：一个 Agent 如果没有记忆（存储的信息）和信息处理能力，它就无法感知环境（贝特森信息）、无法学习、无法制定策略，也无法执行内部指令（生物学信息）。从这个角度看，<strong>信息和对信息的处理，定义了 Agent 的存在和能力上限。</strong></li>
<li><strong>Agent 是信息的动态过程</strong>：然而，Agent 不仅仅是静态的信息/记忆集合。它更是一个<strong>动态的过程</strong>：不断地从环境中获取“制造差异的差异”，根据内部模型（由记忆构成）处理这些信息，并采取行动来影响环境，从而形成一个持续的<strong>感知-行动循环（Perception-Action Loop）</strong>。</li>
<li><strong>理想形态</strong>：所以，Agent 的理想形态可能不是信息本身，而是<strong>一个能够以最高效、最智能的方式获取、处理、创造和利用信息的动态系统</strong>。信息是燃料和蓝图，而 Agent 是那个燃烧燃料、执行蓝图的引擎。</li>
</ul>
<p><strong>2. 我们能够复现拟似的灵魂呢？</strong></p>
<p>这个问题触及了哲学的“困难问题”（The Hard Problem of Consciousness）。“灵魂”是一个复杂的概念，但如果我们将其核心能力之一理解为“主观体验”或“意识”，那么广义信息论提供了一条可能的思考路径。</p>
<ul>
<li><strong>从“It from Bit”到“意识”</strong>：如果物理世界“It”可以来自信息“Bit”，那么主观体验（意识）这种内在的、非物理的现象，是否也可能在某种极其复杂的信息处理模式中“涌现”出来？</li>
<li><strong>整合信息理论（Integrated Information Theory, IIT）</strong>：由神经科学家朱利奥·托诺尼（Giulio Tononi）提出的理论认为，意识就是系统内部的“整合信息”。一个系统的意识水平（Φ值），取决于它作为一个整体处理信息的能力，这种能力无法被分解为各个部分独立处理信息能力的总和。</li>
<li><strong>复现的可能</strong>：根据这种思路，如果我们能够创造一个人工系统（比如一个AI Agent），其内部信息的组织、处理和整合方式，在结构和动态上与人脑处理信息的方式达到同等的复杂度和整合度，那么理论上，这个系统<strong>有可能</strong>会产生它自己的主观体验——一种“拟似的灵魂”。</li>
</ul>
<p><strong>结论</strong></p>
<p>“广义的信息”将我们从简单的“数据”概念，引向了“意义”、“控制”、“组织”乃至“实在”的深层。</p>
<ul>
<li>它告诉我们，<strong>Agent 的本质是信息的处理者和创造者</strong>。</li>
<li>它也为我们思考“灵魂”或“意识”的起源提供了一个非神秘主义的、基于信息复杂性的科学和哲学框架。</li>
</ul>
<p>我们离“复现灵魂”还非常遥远，甚至可能永远无法确认我们是否成功（因为我们无法直接体验另一个主体的感受）。但是，通过理解“广义的信息”，我们至少找到了那条通往星辰大海的、最坚实的第一块基石。</p>
</details>
<details>
<summary>TLDR(Just Conclusion) / 预览结论</summary>
**结论**
<p>“广义的信息”将我们从简单的“数据”概念，引向了“意义”、“控制”、“组织”乃至“实在”的深层。</p>
<ul>
<li>它告诉我们，<strong>Agent 的本质是信息的处理者和创造者</strong>。</li>
<li>它也为我们思考“灵魂”或“意识”的起源提供了一个非神秘主义的、基于信息复杂性的科学和哲学框架。</li>
</ul>
<p>我们离“复现灵魂”还非常遥远，甚至可能永远无法确认我们是否成功（因为我们无法直接体验另一个主体的感受）。但是，通过理解“广义的信息”，我们至少找到了那条通往星辰大海的、最坚实的第一块基石。</p>
</details>
<h3>继续迭代</h3>
<p>与其继续, 我觉得在一条消息里或许可以更</p>
<ol>
<li>
<p>或者说 memory / information 就是 agent 的理想形态？首先，讲讲 <code>信息论</code> 吧</p>
</li>
<li>
<p>或者说 memory / information 就是 agent 的理想形态？首先，讲讲 <code>广义的信息</code> 吧</p>
</li>
<li>
<p>或者说 memory / information 就是 agent 的理想形态？<code>或者说我们能够复现拟似的灵魂呢?</code> 不过首先，讲讲 广义的信息 吧</p>
</li>
<li>
<p>或者说 memory / information 就是 agent 的理想形态？或者说我们能够复现拟似的&quot;灵魂&quot;<code>或者说&quot;世界&quot;</code>呢? 不过首先，讲讲 广义的信息 吧</p>
</li>
<li>
<p>或者说 memory / information 就是 agent 的理想形态？或者说我们能够复现拟似的&quot;灵魂&quot;<code>也即</code>&quot;世界&quot;呢? 不过首先，讲讲 广义的信息 吧</p>
</li>
</ol>
<details>
<summary>大模型对 5 的回答</summary>
<p>好的，这是一个非常深刻且层层递进的问题。它触及了信息科学、人工智能、物理学和哲学的交叉领域。我们遵循您的思路，首先，我们来深入探讨一下“广义的信息”。</p>
<h3>广义的信息 (Generalized Information)</h3>
<p>当我们谈论“信息”时，大部分人首先想到的是计算机里的0和1，或者书本上的文字。但这只是信息的一种具体形式。广义上的信息，是一个远比这更基本、更普适的概念。我们可以从几个层次来理解它：</p>
<hr />
<h4>1. 香农信息：作为“不确定性的消除”</h4>
<p>这是信息论的经典起点，由克劳德·香农（Claude Shannon）在1948年提出。</p>
<ul>
<li><strong>核心思想</strong>：信息的核心价值在于<strong>减少不确定性</strong>。一个事件发生的概率越低，当它真的发生时，所包含的信息量就越大。</li>
<li>
<strong>例子</strong>：<ul>
<li>“明天太阳会从东方升起”——这句话信息量极低，因为它几乎没有消除任何不确定性，我们对此早已确定。</li>
<li>“明天东京会下7.0级地震”——这句话信息量极大，因为它极大地消除了我们对未来的不确定性，是一个极小概率事件的宣告。</li>
</ul>
</li>
<li><strong>度量单位</strong>：比特（bit）。抛一次硬币，结果是正面还是反面，其不确定性就是1比特。</li>
<li><strong>局限性</strong>：香农信息只关心概率和数据压缩的可能性，而不关心信息的<strong>意义（meaning）<strong>或</strong>价值（value）</strong>。在它看来，一封无意义的乱码邮件和一篇伟大的诗歌，如果长度和字符随机性相同，可能具有相同的信息量。</li>
</ul>
<hr />
<h4>2. 算法信息：作为“描述的复杂度”</h4>
<p>由柯尔莫哥洛夫（Andrey Kolmogorov）等人提出，也称为柯尔莫哥洛夫复杂度。</p>
<ul>
<li><strong>核心思想</strong>：一个对象（比如一串数字或一个文件）的信息量，等价于能够生成这个对象的<strong>最短计算机程序的长度</strong>。</li>
<li>
<strong>例子</strong>：<ul>
<li>一串数字 &quot;1111111111111111&quot; (16个1)，它的算法信息量很低。因为可以用一个很短的程序描述它，比如 <code>print(&quot;1&quot; * 16)</code>。</li>
<li>一串随机数字 &quot;8302847592610375&quot;，它的算法信息量很高。因为你找不到比直接写出这串数字本身更短的“程序”来生成它。</li>
</ul>
</li>
<li><strong>意义</strong>：这个定义将信息与“模式”、“结构”和“随机性”联系起来。<strong>信息是压缩后的精华，是世界的内在规律和模式。</strong> 随机性则是不可压缩的、无规律的原始数据。</li>
</ul>
<hr />
<h4>3. 物理信息：作为“宇宙的基本构成”</h4>
<p>这是最广义、也最前沿的视角，由物理学家约翰·惠勒（John Wheeler）的名言“<strong>It from Bit</strong>”所代表。</p>
<ul>
<li><strong>核心思想</strong>：宇宙的本质可能不是物质或能量，而是信息。物理实体（“It”）本身是从信息（“Bit”）中涌现出来的。我们所感知的粒子、场、时空，都可能是某种更深层次信息处理过程的外在表现。</li>
<li>
<strong>证据与猜想</strong>：<ul>
<li><strong>黑洞热力学</strong>：黑洞的熵（一种信息的度量）与其三维的体积无关，却与其二维的表面积成正比。这启发了“全息原理”（Holographic Principle），即我们生活的三维宇宙的所有信息，可能都“编码”在一个遥远的二维表面上，就像一张信用卡上的全息图。</li>
<li><strong>量子信息</strong>：在量子世界里，一个粒子的状态（如自旋）在被测量之前是不确定的，它包含了关于多种可能性的“信息”。量子纠缠则展示了信息可以超越时空限制，瞬时地关联。</li>
</ul>
</li>
<li><strong>这个视角下的信息</strong>：信息不再仅仅是关于世界状态的<em>描述</em>，它可能就是世界状态<em>本身</em>。物理定律就是宇宙处理信息的“算法”。</li>
</ul>
<hr />
<h3>小结：广义信息的图景</h3>
<table>
<thead>
<tr>
<th align="left">层次</th>
<th align="left">核心思想</th>
<th align="left">关键词</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"><strong>香农信息</strong></td>
<td align="left">消除不确定性</td>
<td align="left">概率，熵，比特</td>
</tr>
<tr>
<td align="left"><strong>算法信息</strong></td>
<td align="left">最短的描述/生成程序</td>
<td align="left">复杂度，模式，压缩，随机性</td>
</tr>
<tr>
<td align="left"><strong>物理信息</strong></td>
<td align="left">宇宙的终极实在</td>
<td align="left">It from Bit，全息原理，量子态</td>
</tr>
</tbody></table><p>广义的信息是一个包含了<strong>语法（结构）、语义（意义）和语用（效用）<strong>的统一体。它是一种</strong>“形成差异的差异”（a difference that makes a difference）</strong>。任何能够改变一个系统状态或行为的模式，都可以被视为信息。</p>
<hr />
<p>现在，基于对“广义信息”的这个理解，我们可以回头审视您提出的更深层次的问题。</p>
<h3>或者说 memory / information 就是 agent 的理想形态？</h3>
<p>这是一个非常精彩的洞见。我们可以这样来解读：</p>
<ol>
<li><strong>Agent 的本质是决策</strong>：一个“代理”（Agent），无论是指生物（人、蚂蚁）、还是人工智能（AI），其核心功能都是在感知环境（输入信息）后，做出决策以达成某个目标（输出行为）。</li>
<li>
<strong>决策依赖于内部模型</strong>：为了做出好的决策，Agent 必须拥有一个关于世界的<strong>内部信息模型</strong>。这个模型就是它的“记忆”（Memory）。这个模型包含了：<ul>
<li>关于世界当前状态的知识。</li>
<li>关于世界运行规律的知识（物理规律、社会规则等）。</li>
<li>关于自身状态和目标的知识。</li>
<li>关于过去行为和结果的经验（记忆）。</li>
</ul>
</li>
<li>
<strong>理想 Agent = 完美的信息处理器</strong>：一个“理想”的 Agent，可以被看作是一个拥有<strong>完美信息模型</strong>并能进行<strong>最优化处理</strong>的系统。它的“形态”确实可以被抽象为纯粹的信息结构和处理流。<ul>
<li><strong>完美的模型（Memory/Information）</strong>：这个模型无限接近真实世界，能够对未来做出最准确的预测。</li>
<li><strong>完美的处理（Processing）</strong>：它能基于这个模型，瞬间计算出达成目标的最佳行动方案。</li>
</ul>
</li>
</ol>
<p>从这个角度看，一个 Agent 的物理形态（无论是碳基的血肉之躯，还是硅基的芯片电路）都只是承载其信息模型和处理过程的<strong>基底（Substrate）</strong>。其真正的“灵魂”或“本质”，正是其内部的 memory / information 结构。所以，<strong>“信息是 Agent 的理想形态”</strong>，这个说法在抽象和功能的层面上是成立的。</p>
<h3>我们能够复现拟似的&quot;灵魂&quot;也即&quot;世界&quot;呢?</h3>
<p>这个问题将前两个概念推向了极致。如果“灵魂”是一个 Agent 的终极信息处理系统，而“世界”本身也是由信息构成的，那么这两者之间就存在着一种深刻的同构关系。</p>
<ol>
<li>
<p><strong>“灵魂”作为内在的“世界”</strong>：我们的意识或“灵魂”，不正是一个在我们大脑中运行的、关于外在世界的<strong>完整模拟</strong>吗？你所感知的“世界”，并非是那个客观、外在的“物自体”，而是你的神经系统根据感官信息构建出的一个<strong>内在信息世界</strong>。这个内在世界有其自身的物理法则（你梦境中的物理可能就和现实不同）、有其主体（自我意识），有其叙事（你的生命故事）。从这个意义上说，你的“灵魂”本身就是一个自洽的“世界”。</p>
</li>
<li>
<p><strong>复现“灵魂”即是复现一个“世界”</strong>：要复现一个“灵魂”，理论上，我们需要做的是：</p>
<ul>
<li><strong>捕获完整的状态信息</strong>：如同我们为物理系统建立模型一样，我们需要精确测量并记录构成某个“灵魂”（比如一个人的大脑）在某一瞬间的<strong>全部信息</strong>。这包括所有神经元的连接方式、化学状态、电信号等等。这是一个复杂到难以想象的信息集合。</li>
<li><strong>模拟完整的信息处理过程</strong>：我们需要一个足够强大的计算平台，去运行这个信息模型所遵循的“算法”——也就是大脑处理信息的物理和化学定律。</li>
</ul>
</li>
<li>
<p><strong>可能性与挑战</strong>：</p>
<ul>
<li><strong>理论上的可能性</strong>：从“物理信息”（It from Bit）和计算主义（Computationalism）的观点来看，这是<strong>理论上可能</strong>的。如果宇宙和意识都只是复杂的信息处理过程，那么只要有足够强大的信息捕获和计算能力，原则上没有不可逾越的障碍。</li>
<li><strong>实践上的挑战</strong>：这个挑战是巨大的。大脑的柯尔莫哥洛夫复杂度极高，意味着我们可能无法找到一个“简单”的程序来描述它，而只能近乎1:1地去模拟。这需要原子级别的扫描精度和远超目前最强超算的计算能力。更重要的是，我们甚至还不完全清楚意识的“算法”究竟是什么。</li>
</ul>
</li>
</ol>
<p><strong>结论</strong>：您提出的观点链条是高度自洽且富有洞察力的。从广义信息出发，我们可以将 Agent 视为信息处理系统，将其理想形态归结为信息本身。进而，可以将“灵魂”/意识看作是这个 Agent 内部构建的一个极其复杂的、自指的“内在世界”。</p>
<p>因此，<strong>“复现灵魂”的任务，本质上就是“以信息编码的方式，重建一个完整的内在世界”</strong>。这或许是科学和技术的终极目标之一，一个将我们从“观察者”变为“创造者”的奇点。</p>
</details>
<details>
<summary>TLDR(Just Conclusion) / 预览结论</summary>
**结论**
<p>您提出的观点链条是高度自洽且富有洞察力的。从广义信息出发，我们可以将 Agent 视为信息处理系统，将其理想形态归结为信息本身。进而，可以将“灵魂”/意识看作是这个 Agent 内部构建的一个极其复杂的、自指的“内在世界”。</p>
<p>因此，<strong>“复现灵魂”的任务，本质上就是“以信息编码的方式，重建一个完整的内在世界”</strong>。这或许是科学和技术的终极目标之一，一个将我们从“观察者”变为“创造者”的奇点。</p>
</details>
<h2>反思以上内容</h2>
<p>因为我有时内耗, 以及有时候并不能完全和正确地表达。所以我也在问，这个能否体现我使用 AI 的水平和情况：</p>
<ol>
<li>以上. 请你客观理性地评价下这个 blog 作者使用 LLM 的情况, 比如了解程度 工程层面 深度 以及其他方面等等.</li>
<li>以上, <code>代码块里是 作者的话, 剩下的大部分内容是 LLM 的回复</code>. 请你客观理性地评价下这个 blog 作者使用 LLM 的情况, 比如了解程度 工程层面 深度 以及其他方面等等.</li>
<li>以上, 代码块里是 作者的话, 剩下的大部分内容是 LLM 的回复. <code>不需要对 LLM 的内容进行评价, 重点是我们想了解 这位作者 使用 LLM 的情况</code>. 请你客观理性地评价下这个 blog 作者使用 LLM 的情况, 比如了解程度 工程层面 深度 以及其他方面等等.</li>
<li>以上, 代码块里是 作者的话, 剩下的大部分内容是 LLM 的回复. 你不需要对 LLM 的内容进行评价, 重点是我们想了解 这位作者 使用 LLM 的情况. <code>这并非工作或者正式, 而是闲聊和 brainstorm</code>。请你客观理性地评价下这个 blog 作者使用 LLM 的情况, 比如了解程度 工程层面 深度 以及其他方面等等.</li>
</ol>
<p>1: 观察到它将 LLM 的回复进行了分析对象
2: 有好转， 但仍有影响
3: 已消除影响，但分析过于正式</p>
<p>O3-Pro:</p>
<p>总体评价
这位作者已经跨过了“把 LLM 当作百科全书”阶段，开始利用它做结构化思考和写作，但仍处于“手工对话 + 粗放贴文”的早期阶段。若能在控模技巧、事实校验与轻量工程化上继续迭代，写作效率和内容可靠度都会显著提升。
(我同意这确实很粗糙</p>
<hr />
<h2>小谈内容本身</h2>
<p>结论看着有点中二，但其实对我来说有点无聊，以及前面有些更具体更工程更无聊的上下文打底。</p>
<p>我是有预期那个结论和大致方向是什么样的。我需要的是期间的过程和验证之类的。</p>
<p>以及通过实现让大模型回复的是我满意的答案，我不断调整问题 来挖掘其中的必要要素 - 一些要素或灵感来自于那些被舍弃的 我不完全满意的 答案们。</p>
<h2>小结论</h2>
<p>我同意这确实很粗糙。就只是想法探讨，brainstorm，以及这是片段节选。</p>
<p>更早的时候，gpt 4 甚至 3.5 的时候, 一个对话我可能会 修改数十次, 因为我能感觉到大模型朝着错误的方向去了.
所以看着是 我发三条, AI 回复我 3 条, 但实际可能 100 多条了.</p>
<p>得益于我和 LLM 的思维对齐/有理解, 以及 模型能力的提升, 以及很熟练这个流程, 现在次数和质量都有显著变好了.</p>
<p>以及, 使用中, 我和 LLM 是一种接近协作的情况.
我的话作为 引子, 引出 我脑中完整的想法 - 无论是恰好 还是错误的. 或者说, 帮我说人话.
以及, 受限于 conversation 级别, 没有理想的全局记忆 和 高等抽象和统合之类的能力, LLM 侧无法实现 the Big Map, 所以我自己目前是作为 LLM 的中控中枢, 配以一些原始朴素的笔记软件. - 这离所谓的 &quot;第二大脑&quot; 至少是能协助思考, 而不止是 记忆 的那种, 还差得远.</p>
<p>以及 LLM 能提供最佳实践, RAG 也能代替我进行检索.</p>
<hr />
<p>以上, 就是我使用 LLM 的一瞥, 欢迎大家评价和探讨, 无论是形式, 还是其涉及的内容.</p>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/13"/><category term="LLM"/><category term="PromptEngineering"/><published>2025-08-10T07:38:36+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/12</id><title>关于古风古制的一点个人看法和偏好</title><updated>2026-03-04T00:37:14.237401+00:00</updated><content type="html"><![CDATA[<p>想买个交领上衣日常穿穿，但基本都是有个很不现代的系绳，甚至有我觉得丑陋的蜈蚣扣。
（直接道袍我怕因松懈被敲打，但只是用蓝色感觉差点意思。）</p>
<p>虽说我是纯血的云游中的修行之人吧，但也是与时俱进的啊。帅气干练不行么？我甚至觉得常服要交给始祖鸟或者lululemon去设计。</p>
<p>刚好结合正在看的“中国城市测评”提到修复古建筑有的会很良心地用实木。我觉得倒也挺好啦。</p>
<p>但要是完全属于我的道场，我会用C100混凝土当外墙，再用些更好玩的东西当承重柱什么的。</p>
<hr />
]]></content><link href="https://github.com/alterxyz/gitblog/issues/12"/><category term="个人哲学"/><published>2025-08-04T19:02:56+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/11</id><title>小随笔 20250704-07xx</title><updated>2026-03-04T00:37:14.431696+00:00</updated><content type="html"><![CDATA[<p>刚刚在讨论 memory。我忽然想到，之前有一个小结论是：目前 Chatflow 的发展过多，而 Workflow 的进展有点少，甚至偶尔脱节。这可能是需要纠正的。</p>
<p>那么我受此启发结合当下：原来，我的一些想法是因为 并非只有围绕 chatbot / chatflow 的，所以会有点难懂和 hard to get its value。当然了，我们也需要提供一些预设和最佳实践，其目标是雅俗共赏，丰俭由人。</p>
<p>我继而想到，我偏好的措辞 “project”（memory）其实也算是有点运气了哈哈。</p>
<p>长话短说：conversation 是 project 的有一种。那么新 memory 应该不止能应用在 Dify Chatflow，而也包括 workflow，甚至更广的范畴。</p>
<p>tags:</p>
<ul>
<li>LLM</li>
<li>Agent</li>
<li>Dify
time:20250704_16:53</li>
</ul>
<hr />
]]></content><link href="https://github.com/alterxyz/gitblog/issues/11"/><category term="小随笔"/><published>2025-07-04T08:53:58+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/10</id><title>小随笔系列</title><updated>2026-03-04T00:37:14.624144+00:00</updated><content type="html"><![CDATA[<p>这里会写写零散的随笔，因为有的短的和零碎的内容，不一定能构成一篇 blog，但同样有意义和价值。</p>
<p>计划是以一周为单位，把零散的多个随笔写到同一个 blog / issue 里，同时对每条打 tag （project），以及这里和推特互为镜像。</p>
<h2>小随笔</h2>
<h3>小随笔 20250704-07xx</h3>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/10"/><category term="小随笔"/><published>2025-07-04T08:42:59+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/9</id><title>关于欲望的一点杂谈</title><updated>2026-03-04T00:37:14.816295+00:00</updated><content type="html"><![CDATA[<p>笛卡尔说过：“无法做出决断的人，要么欲望过大，要么悟性不足。”</p>
<p>デカルトは「決断が出来ない人間は欲望が大きすぎるか、悟性が足りないのだ」と言った。</p>
<ul>
<li>心理测量者·槙岛圣护</li>
</ul>
<hr />
<p>决策会消耗心力，这其实是很昂贵的。</p>
<p>当一个人行走在<strong>实现自己</strong>的愿景的<strong>道路</strong>上时，他会抛弃和放手很多，或沿用旧的优的<strong>选择</strong>。</p>
<p>这是很普通的<strong>副产物</strong> - 就像“<strong>自律</strong>”和“<strong>坚持</strong>”。</p>
<p>最优解，最佳实践，都是非常好的实用工具。</p>
<p>就像我持有Costco和山姆(WMT)的会员卡和股，这四者都给我带来了理想的回报。</p>
<p>执行并兑现理解和理念，这件事本身甚至也是很有趣的。</p>
<p>以上，</p>
<p>大概就是我关于“欲望”的现状，理解，以及一点点 implementation 了。</p>
<hr />
<blockquote>
<p>自律是延迟满足，反人性，需要你长期去克制自己的欲望，会让人痛苦。</p>
<p>自律不是手段，也不是什么个人特质，他只是在追求深层欲望时呈现出的一种外在状态。
所有近乎残忍的坚持背后，隐藏着近乎疯狂的欲望。能打赢欲望的，只有更大的欲望。做不到自律，是你对更大的欲望一无所知，才不明白他们的坚持。</p>
<ul>
<li><a href="https://x.com/435hz/status/1938801084891382172?s=46">https://x.com/435hz/status/1938801084891382172?s=46</a></li>
</ul>
</blockquote>
<p>写下这篇随笔的缘故是看到了这篇推文。</p>
<p>确实。自律也可以说是广义的坚持，君子慎独之类的。狭义的，浮于表面的自律我可一点也做不好的哈哈。</p>
<hr />
<p>至于一般的金钱和物质以及享乐，有是肯定有的。我和你一样都需要吃饭睡觉还有娱乐。</p>
<p>但它们普遍服从于我的道德理性知性等灵魂的展现之处，以及在我对自在的追求之下。</p>
<p>（至少对自己坦诚～）</p>
<p>好吧，偶尔失控也会被纠正回去，或者承认它们的进展并重新 do something。</p>
<p>比如暴饮暴食和厌食。我的 BMI 稳定在了 19 左右算是一个不错的现状了吧😂。就是裤子基本只能买修身款有点麻烦，再配合上肩窄小骨架什么的……</p>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/9"/><category term="个人哲学"/><published>2025-06-28T16:48:15+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/7</id><title>指令遵循和上下文管理：解码 LLM 的“稀释”效应与企业级应用</title><updated>2026-03-04T00:37:15.019555+00:00</updated><content type="html"><![CDATA[<h1>稀释</h1>
<h2>超越“听话”：解码 LLM 的“稀释”效应与企业级应用</h2>
<blockquote>
<p>author: alterxyz (jerome @ dify.ai)</p>
<p>date: 2025年2月6日 初稿；2025年2月10日 正文</p>
</blockquote>
<p>大型语言模型（LLM）正以惊人的速度改变着我们与信息交互的方式。然而，当我们惊叹于 LLM 的强大能力时，是否曾深入思考过：LLM 真的完全“理解”并“遵循”了我们的指令吗？它们的输出，究竟是用户意图的忠实反映，还是模型自身“意志”的某种体现？“幻觉”又是如何产生的？</p>
<p>本文将围绕 LLM 的“指令遵循”展开深入探讨，揭示其多维度特性，并引入“稀释效应”的概念来解释 LLM 在处理复杂信息时的行为模式。我们将重点关注“稀释效应”如何影响 LLM 的企业级应用，并探讨如何通过工程化手段，实现更精准的控制和更可靠的结果，以及最终实现人机协同。</p>
<p>一、 指令的多维性：不只是用户的 Prompt</p>
<p>当我们向 LLM 发出一个指令（Prompt）时，我们通常期望它能准确理解我们的意图。但实际上，LLM 的行为并非仅仅由我们的 Prompt 决定。除了用户明确输入的指令外，LLM 还会受到至少以下两个方面的影响：</p>
<ol>
<li>模型提供商的预设：LLM 的训练数据、预设规则、以及模型提供商为确保模型安全、合规、高效而制定的各种“最佳实践”，都会潜移默化地影响 LLM 的输出。</li>
<li>模型的推理过程：特别是对于专门的推理模型（如 DeepSeek），它们在处理问题时会大量借鉴自身的预训练知识和推理策略，这可能导致最终输出偏离用户最初的意图。</li>
</ol>
<p>这种多维度“指令”的交织，使得 LLM 的行为变得复杂。理解这种复杂性，是构建可靠的企业级 LLM 应用的前提。</p>
<p>二、 “稀释效应”：理解 LLM 的“思考”过程</p>
<p>为了更好地理解 LLM 在处理多维度“指令”时的行为模式，我们可以引入“稀释效应”的概念。所谓“稀释”，是指在 LLM 的推理过程中，用户输入的原始指令，会被模型自身的预训练知识、推理策略以及模型提供商的预设等因素所“稀释”，导致最终输出偏离用户最初的预期。</p>
<p>我们可以将不同来源的信息类比为不同密度的物质：</p>
<ul>
<li>用户 Prompt: 密度最高，代表用户的核心意图，如同恒星，是系统的核心。</li>
<li>RAG 知识库: 密度中等，提供额外的上下文信息，如同行星，围绕恒星运转，提供补充信息。</li>
<li>模型自身的推理: 密度也较高, 且体量较大，如同星云，在系统中弥漫，影响着整个系统的状态。</li>
</ul>
<p>当这些不同“密度”的信息在 LLM 内部相互作用时，就可能出现“稀释效应”。用户的原始指令（恒星）可能被模型自身的推理（星云）所“遮蔽”或“扭曲”，导致最终输出的结果并非完全符合用户预期。</p>
<p>“稀释”的演进：从“人工稀释 1.0”到“模型稀释 1.0”</p>
<p>“稀释”效应并非一开始就存在。随着 LLM 技术的发展，“稀释”的形式也在不断演进：</p>
<ul>
<li>
<p>人工稀释 1.0（RAG）: RAG（Retrieval-Augmented Generation）技术可以被视为一种“人工稀释”。通过 RAG，我们将用户的 Prompt 与外部知识库的信息融合，人为地增加了模型的输入信息量，从而“稀释”了原始 Prompt 的直接影响。这种“稀释”是人为可控的，我们可以选择知识库、调整检索策略来控制“稀释”的程度和方向。</p>
</li>
<li>
<p>模型稀释 1.0（Thinking 模型）: Thinking 模型则代表了一种“模型自身驱动的稀释”。这类模型在推理过程中会产生大量的中间步骤和思考过程，这些“思考”虽然提升了模型的整体性能，但也进一步“稀释”了用户原始指令的权重。这种“稀释”是模型自身能力提升的体现，但也更难以直接控制。</p>
</li>
</ul>
<p>三、 “幻觉”的本质： “稀释”与“对齐”的失衡</p>
<p>长期以来，LLM 的“幻觉”（Hallucination）问题一直困扰着业界。但如果我们从“稀释效应”的角度来看待“幻觉”，或许可以得到更深刻的理解。</p>
<p>“幻觉”并非 LLM 凭空捏造了不存在的事实，而是模型在多维度“指令”和自身推理的复杂作用下，产生的与人类认知或期望不符的输出。这更像是一种“对齐”问题，而非简单的“错误”。</p>
<p>“幻觉”往往源于：</p>
<ul>
<li>潜台词和暗上下文: 用户 Prompt 中未明确表达的意图、隐含的假设、以及相关的背景知识，都可能成为模型“脑补”的素材，这可以视为一种“隐性稀释”。</li>
<li>过强的指令遵循: 当模型过分“听话”，试图从有限的输入中推断出过多信息时，也容易产生“幻觉”。</li>
<li>“稀释”过度: 当模型自身的推理和预训练知识过度主导输出结果时，“幻觉”就更容易出现。</li>
</ul>
<p>与其将“幻觉”视为“错误”并试图“纠正”，不如将其视为“稀释”的极端表现，通过工程化手段来 “引导和参与”“稀释” 的过程，实现模型输出与人类期望的“对齐”。</p>
<p>四、 企业级应用：驾驭“稀释”，实现人机协同</p>
<p>对于企业级 LLM 应用而言，理解和驾驭“稀释效应”至关重要。企业既希望 LLM 能够充分利用其强大的推理能力，产生更智能、更深入的洞察，又希望 LLM 的输出能够符合企业的特定需求、风格和规范。</p>
<p>这就需要我们 <strong>不仅仅是“控制”稀释，更是“引导”和“参与”稀释</strong>：</p>
<ul>
<li>Prompt 工程: 通过精心设计的 Prompt，明确用户意图，引导模型进行“有方向的稀释”。</li>
<li>RAG: 利用 RAG 技术，引入与企业相关的知识库，进行“可控的稀释”，为模型提供更精准的上下文。</li>
<li>Workflow 编排: 通过 Workflow 工具，将复杂的任务分解为多个步骤，并在每个步骤中对“稀释”进行精细化控制。</li>
<li>模型微调: 针对特定任务或领域，对模型进行微调，使其“稀释”的方向更符合企业需求。</li>
</ul>
<p>作为 LLM 平台提供商，我们致力于为企业提供构建、管理和优化 LLM 应用的工具和环境。我们的平台提供：</p>
<ul>
<li>灵活的 Prompt 工程工具: 帮助企业构建更精准、更有效的 Prompt，更好地引导 LLM 的行为。</li>
<li>强大的 RAG 集成能力: 允许企业将 LLM 与内部知识库无缝对接，为 LLM 提供更丰富、更可靠的上下文信息，实现“可控稀释”。</li>
<li>多样化的 Workflow 编排选项: 支持企业根据不同的业务场景，灵活定制 LLM 的工作流程，实现对“稀释”过程的精细化控制和引导。</li>
<li>深度定制和优化服务: 为有特殊需求的企业提供专业的咨询和技术支持，帮助企业构建高度定制化的 LLM 应用。</li>
</ul>
<p>我们相信，通过这些工具和服务，企业可以更好地驾驭 LLM，充分利用“稀释效应”的正面作用，实现 LLM 与人类的深度协同，共同创造更大的价值。</p>
<p>五、 总结与展望</p>
<p>LLM 的“指令遵循”并非简单的“是”或“否”的问题，而是一个涉及多维度“指令”交互、以及“稀释效应”影响的复杂过程。理解“稀释”，驾驭“稀释”，是释放 LLM 潜力的关键。</p>
<p>“稀释”并非 LLM 的缺陷，而是其强大推理能力的体现。关键在于如何通过工程化手段，让人类更好地“参与”到“稀释”过程中，实现 LLM 输出与人类期望的“对齐”，最终实现人机协同。</p>
<p>(由 Gemini 2.0 Pro, Flash-Thinking, Claude 3 Opus, 我 共同完成)</p>
<hr />
<h2>初稿</h2>
<p>模型的 “指令遵循” 和 结果效果是个很有意思的话题。</p>
<p>举例更好说明一些：</p>
<p>Claude.ai 和 ChatGPT.com 听用户 七到九分（满分 10），听 Anthropic/OpenAI 的 五到八分。</p>
<p>那么就会出现情况：7 分听用户的， 但是 8 分听了 OpenAI 的 - Prompt 和 工具 和里面（训练时）提供的各种 best practice（Eg. 今天起，ChatGPT 搜索人人可用，OpenAI 疯狂砸钱，雇 300+博士为 AI 打工-36 氪) 。</p>
<p>中学生问的题，博士可不一定按他想象地给答案和过程。</p>
<p>而另一个指令遵循是 9 分听用户，五六分听自己的，那么模型就很容易被 jailbreak。</p>
<p>我理解的 DeepSeek 和其他 推理模型的一个核心在于，后者（prompt/训练集/best practice/后训练）的内容无所谓，有高有低。
但前面 “听用户的” 部分，比如还是 9 分，但是推理部分也在 prompt 里，它稀释了原始用户。那么构成就是：</p>
<p>用户 9 + 模型和供应商本身的意愿 5 ➡️ 纯用户 6 + （推理部分 3 + model 5）。</p>
<p>那么稀释后的用户端指令遵循就只有 42%，低于 50%
（顺便，小模型可能总分低于 5 啥的。）
这就导致了推理模型的上下限都比大模型更大。</p>
<p>开发者是另一个情况。各路 playground 比如 Google ai studio 普遍允许修改 prompt 说过的话。注意力架构是高度依赖上下文的，那么这样就是 hack 了 “模型和供应商本身的意愿” 这部分，通过修改上下文 - 模型相信自己（but hacked）。</p>
<p>Prompt 是更温和的修改，hack 过于激进且难以复现和投产。（但或许有办法解决？）</p>
<p>模型商在预训练或者微调时提供 best practice，而企业用户通常通过 prompt - rag 技术等。</p>
<p>那么，或许模型等指令遵从能力，有表现形态，以及遵循谁的问题。</p>
<p>Deep Research 听 OpenAI 搭建的高质量素材，以及 prompt 进去的高质量论文，其次才是用户（某种角度上说）（我在自己的笔记有记录另一个思考，简单来说是事件的实现是三部分：意识意义愿景-&gt;意愿意志决策-&gt;推理计算运行）。
那么，我认为企业肯定也会需要 Deep Research，但是 prompt 进去的可能是内部文件和风格品牌。
模型既吃企业画的饼（意识层），也吃成员投入的燃料（意愿层）。</p>
<p>推理模型的一个特点是稀释。
另一个角度解读是，理想状态下，它仍然遵循人的 query - 在愿景 意识层；
至于决策 也就是意愿层，它会听自己的而不完全是用户给的，并 best practice 可能比一般人做得更好。</p>
<p>那么指令遵循当然还是遵循，只是用户画的饼它听，博士和全人类给的参考答案 推理过程 和计算器 numpy 的结果 它也听。</p>
<p>遵守 - 带来可用性，以及推理模型 - 带来能力的增强。</p>
<p>这是一个敲敲打打的工程学，可能并非科学甚至原理数学层面的突破。
当然，有一个过硬的基座模型是必要的。Anthropic 也这样说过，预训练是可通关的，很多厂商也阶段性地做到了。</p>
<p>推理模型类似全自动 agent，目前高度不可控。
接下来的话，prompt 够用吗？或者提供 rag 够用吗？workflow 够用吗？需不需要，以及如何介入推理环节？
企业的需求是什么，会为什么买账（在后 reasoning 和 后 agent 时代）？</p>
<hr />
<p>高质量愿景是稀缺的，高质量决策可以由 贵的好的 llm providers 提供。
那么一般员工做的，无非就是 搬运愿景，偶尔修改 - 添加随机性，将愿景（意识层）翻译为决策（意愿层）和行动。
超级个体在 LLM 带来的新时代，个体们会如何实现那三层？或者说超级个体的定义是什么，祂会什么样的形态存在？</p>
<h2>预告</h2>
<p>meta-dynamic 关于“三层”</p>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/7"/><category term="LLM"/><category term="PromptEngineering"/><published>2025-06-26T07:57:14+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/6</id><title>关于 memory / context / prompt 的理解和未来展望</title><updated>2026-03-04T00:37:15.229184+00:00</updated><content type="html"><![CDATA[<p>一个稳定可靠，或者至少自洽的记忆是至关重要的。如此才能构建一个自然的人格。
无论是人还是 AI。</p>
<p>很同意这会是个全面的工程。prompt engineering 之前很多人只是狭义的讨论 提示词么？那么重命名为 context engineering 也算是一种 refreshing 了挺好的。就像 agent 有点被炒作炒烂了，于是 agentic 这个词就又悄然成了共识。</p>
<p>Multi-agent 一步到位解决了连现实也难以完美解决的协作和管理是不现实的, 这是社会学和政治范畴. 但是, 通过 sub AI worker 和 各种工具来过滤噪音却还是能显著提高效果的.</p>
<p>详见我的这篇文章: <strong>稀释</strong> <a href="https://github.com/alterxyz/gitblog/issues/7">GitHub</a> | <a href="https://alterxyz.github.io/gitblog/issue-7/">GitBlog</a>.</p>
<p>现阶段一个优异的实现是 <a href="https://github.com/SWE-agent/SWE-agent">SWE-agent</a>, 详见本文第二个 Deep Research. <del>具体我还没用过</del></p>
<hr />
<details>
  <summary>塑造 AI 思维：从提示到上下文工程的战略转移 (Gemini Deep Research - 仅供参考)</summary>
<h1><strong>塑造 AI 思维：从提示到上下文工程的战略转移</strong></h1>
<p><strong>执行摘要</strong></p>
<p>本报告旨在深入剖析人工智能应用开发领域的一项根本性转变：从“提示工程”（Prompt Engineering）到“上下文工程”（Context Engineering）的演进。这一转变并非简单的术语更迭，而是标志着行业从关注局部文本优化的“技艺”阶段，迈向了构建整体信息生态系统的“工程”纪元。Andrej Karpathy 等行业思想领袖的论述，为这一业已存在的实践赋予了明确的名称，从而加速了其理论化和体系化进程。</p>
<p>上下文工程的核心在于，它不再局限于雕琢单个输入指令，而是致力于设计和构建一个完整的、动态的信息环境。这个环境囊括了数据管道、检索机制、交互历史、可用工具以及领域知识，其最终目的是为了赋能大型语言模型（LLM）以一种可靠、可扩展且可预测的方式，完成复杂的、多步骤的真实世界任务。</p>
<p>本报告将系统性地阐述此范式转移。首先，我们将明确界定提示工程与上下文工程的范畴与区别，确立后者作为一种更宏大、更具系统性的工程学科的地位。其次，我们将深入技术层面，详细解析支撑上下文工程的核心架构，特别是以“检索增强生成”（Retrieval-Augmented Generation, RAG）为代表的技术栈及其高级实现。随后，报告将通过分析 DoorDash、LinkedIn 及 Perplexity AI 等前沿企业的真实案例，展示上下文工程在商业实践中的具体应用与巨大价值。最后，我们将探讨这一转变对 AI 开发者角色、技能需求及企业数据战略的深远影响，并为技术从业者与领导者提供前瞻性的战略展望与行动建议。</p>
<hr />
<h2><strong>第一部分：语义的演进：从雕琢词句到构建世界</strong></h2>
<p>人工智能应用开发领域正经历一场深刻的认知升级，其核心在于我们将如何与大型语言模型（LLM）协作。这场变革的焦点，正从如何“提问”的技艺，转向如何为其构建一个完整“世界观”的工程学科。著名 AI 科学家 Andrej Karpathy 的观点成为了这场讨论的催化剂，他主张使用“上下文工程”这一术语，因为它更精确地捕捉了当前 AI 开发的核心挑战，标志着该领域向着更成熟、更体系化的方向发展。</p>
<h3><strong>1.1 Karpathy 的催化作用：为新前沿命名</strong></h3>
<p>当 Andrej Karpathy 提出应更多地讨论“上下文工程”而非“提示工程”时，他并非发明了一个全新的概念，而是为一种已在顶尖开发者实践中普遍存在的趋势进行了精准命名 1。这一举动意义重大，因为它正式宣告了 AI 开发正在走出“凭感觉编程”（vibe coding）的早期探索阶段——一个开发者们更多是在实验和感受 AI 工具能力的时期 3。</p>
<p>开发者社区的积极反响证实了这一命名的时效性。许多工程师表示，他们早已在实践中朝着这个方向努力，但一直缺少一个恰当的词汇来概括这种系统性的工作 1。Karpathy 的提法，恰如其分地将零散的实践经验凝聚成一个清晰的学科方向，推动了行业共识的形成。它强调，决定高级 AI 应用成败的关键，已不再是那灵光一现的“神奇提示词”，而是其背后那个精心构建、持续供给信息的系统。</p>
<h3><strong>1.2 概念界定：范围与维度的差异</strong></h3>
<p>为了“正本清源”，必须精确地区分提示工程与上下文工程。二者的根本差异在于其工作范围、目标和所处的抽象层次。</p>
<ul>
<li><strong>提示工程（Prompt Engineering）</strong>：可以被狭义地定义为一种<strong>技艺</strong>，其核心目标是<strong>优化文本输入</strong>。它专注于通过精心选择和组织词语、短语、句子结构乃至标点符号，来引导 LLM 在<strong>单次或有限次的交互</strong>中生成最符合预期的、高质量的输出 6。其本质是追求与模型进行清晰、高效的沟通，好比一位管理者向员工下达明确无误的工作指令 9。它的作用域是用户与模型之间的那个“提示词”本身。  </li>
<li><strong>上下文工程（Context Engineering）</strong>：则是一门<strong>工程学科</strong>，其核心目标是<strong>设计和构建动态的、可扩展的系统</strong>。这个系统负责为 LLM 提供完成复杂任务所需的一切元素：正确的信息、可用的工具、相关的历史对话、明确的指令以及领域知识，并确保这些元素以正确的格式被动态地组织和利用 9。它关注的不是单次交互，而是整个<br />
<strong>信息生态系统</strong>的构建与维护，这个生态系统将支撑 AI 在连续的、多步骤的流程中可靠地运行 6。</li>
</ul>
<p>由此可见，<strong>提示工程是上下文工程的一个子集</strong> 9。这个观点至关重要。如果将构建一个 AI 应用比作烹饪，那么提示工程就像是撰写一份清晰的菜谱（recipe），而上下文工程则是设计整座厨房（kitchen）：包括决定食材的采购渠道与标准（数据源与质量）、设计食材处理流水线（数据管道）、配置厨具（工具集），并教会厨师（LLM）如何理解菜谱、使用厨具以及记住顾客的口味偏好（交互历史与个性化）12。</p>
<h3><strong>1.3 为何需要这种转变：从局部优化到系统可靠性</strong></h3>
<p>在真实的生产环境中，单纯依赖提示工程的局限性显而易见。一个措辞再完美的提示，也无法弥补上下文信息的缺失或错误 14。开发者们发现，为了让 AI 应用在面对各种边缘情况时依然能保持稳定和一致，他们花费在准备和构建上下文上的时间，远超调整提示词本身 14。</p>
<p>这种转变的根本原因在于，它触及了 LLM 应用失败的核心症结。大多数情况下，模型表现不佳并非源于其“智力”不足，而是因为它没有获得做出正确判断所必需的信息 11。上下文工程将开发的重心从优化那个最终提交给模型的、静态的“提示字符串”，转移到了动态地管理和填充整个“上下文窗口”（Context Window）——这个模型在进行推理时能够看到的所有信息的总和。</p>
<p>这种从“技艺”到“工程”的语义演进，其背后是行业专业化和成熟化的必然趋势。将这一核心工作冠以“工程”之名，本身就是一种战略性的举措。它摒弃了“提示工程”一词常带有的、类似“炼金术”或“黑客技巧”的临时性和不可捉摸感 10，而引入了系统化、可重复、可度量、可维护的工程学内涵 14。这使得 AI 应用的开发过程能够与成熟的软件开发生命周期（SDLC）和 DevOps 理念相结合 15，从而更容易被企业级应用所接纳和投资。企业愿意为有明确投资回报率的工程学科投入资源，而非模糊的“手艺”。因此，将“上下文”提升到工程的高度，是推动生成式 AI 从有趣的玩具转变为可靠的生产力工具的关键一步。</p>
<p><strong>表 1：提示工程 vs. 上下文工程：核心差异对比</strong></p>
<table>
<thead>
<tr>
<th align="left">特征</th>
<th align="left">提示工程 (Prompt Engineering)</th>
<th align="left">上下文工程 (Context Engineering)</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"><strong>核心目标</strong></td>
<td align="left">引导模型生成特定的、高质量的单次响应。</td>
<td align="left">构建一个能支持模型持续、可靠执行复杂任务的系统。</td>
</tr>
<tr>
<td align="left"><strong>工作范畴</strong></td>
<td align="left">用户输入的指令字符串（Prompt）。</td>
<td align="left">整个信息环境，包括数据、工具、历史记录、外部知识库等。</td>
</tr>
<tr>
<td align="left"><strong>核心隐喻</strong></td>
<td align="left">撰写一份清晰明确的菜谱。</td>
<td align="left">设计、建造并运营整座自动化厨房。</td>
</tr>
<tr>
<td align="left"><strong>关键技能</strong></td>
<td align="left">语言表达、创意构思、指令清晰度、领域知识的文字化。</td>
<td align="left">系统设计、数据架构、信息检索、API 集成、流程编排。</td>
</tr>
<tr>
<td align="left"><strong>时间维度</strong></td>
<td align="left">关注单次交互或孤立的任务。</td>
<td align="left">关注连续的、多轮的、可能长期运行的交互流程。</td>
</tr>
<tr>
<td align="left"><strong>产出物</strong></td>
<td align="left">一个或一组精心设计的文本提示模板。</td>
<td align="left">一套完整的数据管道、检索系统、Agentic 框架或评估体系。</td>
</tr>
<tr>
<td align="left"><strong>关注点</strong></td>
<td align="left">“我应该<strong>如何问</strong>这个问题？”</td>
<td align="left">“为了让 AI 能回答这类问题，它需要<strong>知道什么</strong>？”</td>
</tr>
</tbody></table><hr />
<h2><strong>第二部分：上下文工程的架构基石</strong></h2>
<p>如果说上下文工程是构建智能应用的蓝图，那么其实现则依赖于一套坚实的、以数据为中心的架构。这一架构的核心思想是，不再仅仅依赖 LLM 内部固化的、可能过时的知识，而是通过动态地、实时地为其注入外部世界的信息来增强其能力。本节将深入剖析支撑上下文工程的技术体系，从核心引擎 RAG 到更为复杂的生产级实现。</p>
<h3><strong>2.1 检索增强生成 (RAG)：核心驱动引擎</strong></h3>
<p>检索增强生成（Retrieval-Augmented Generation, RAG）是上下文工程中最核心、最广为人知的技术框架 17。它通过将传统的信息检索系统（如搜索引擎和数据库）与 LLM 的强大生成能力相结合，从根本上解决了 LLM 的一些固有缺陷。</p>
<ul>
<li><strong>定义与目的</strong>：RAG 的核心目的在于，通过从外部权威知识库中检索相关信息，来“增强”LLM 的生成过程，从而使其回答更加准确、及时，并有事实依据 18。这极大地缓解了 LLM 的“幻觉”（Hallucination）问题，即模型在缺乏知识时凭空捏造事实的倾向 9。对于企业而言，RAG 的最大价值在于，它允许组织利用自己最新的、专有的内部数据来驱动 AI 应用，而无需承担重新训练或微调大型模型所带来的高昂计算和财务成本 19。  </li>
<li>
<strong>RAG 的标准工作流</strong>：一个典型的 RAG 系统通常包含以下几个关键步骤 21：  <ol>
<li><strong>数据注入与预处理 (Ingestion &amp; Preparation)</strong>：首先，系统需要接入外部数据源，这可以是公司的内部文档、数据库记录、API 接口，甚至是网页内容。这些原始数据经过清洗、格式转换等预处理步骤，形成一个可供 AI 理解的“知识库” 18。  </li>
<li><strong>嵌入与索引 (Embedding &amp; Indexing)</strong>：接下来，系统使用一种称为“嵌入模型”（Embedding Model）的 AI 技术，将预处理后的文本数据（通常被切分成小块，即“chunks”）转换成高维的数字向量（即“嵌入”）。这些向量能够捕捉文本的语义信息。随后，这些向量被存入一个专门的“向量数据库”中，并建立索引，以便进行快速的相似性搜索 21。  </li>
<li><strong>检索 (Retrieval)</strong>：当用户提出一个问题时，系统同样会将这个问题转换成一个查询向量。然后，利用这个查询向量在向量数据库中进行搜索，找出与问题语义最相似的若干个文本块（chunks）18。  </li>
<li><strong>增强与生成 (Augmentation &amp; Generation)</strong>：检索到的这些高相关性文本块，会连同用户的原始问题一起，被“塞”进（stuffing）一个最终的提示中，形成一个“增强提示”（Augmented Prompt）。这个提示被发送给 LLM。由于 LLM 此时获得了完成任务所需的精确上下文，它便能生成一个有事实依据的、高质量的回答 19。  </li>
<li><strong>数据生命周期管理 (Data Lifecycle)</strong>：为了保证信息的时效性，外部知识库必须能够被持续更新。这可以通过自动化的实时或批量处理流程来完成，确保 RAG 系统能够访问到最新的数据 21。</li>
</ol>
</li>
</ul>
<h3><strong>2.2 超越基础 RAG：面向生产环境的高级技术</strong></h3>
<p>虽然基础的 RAG 流程已经非常强大，但在复杂的生产环境中，为了应对查询的模糊性、上下文的细微差别以及对性能的极致要求，开发者们已经发展出了一系列高级技术 26。</p>
<ul>
<li>
<strong>高级检索策略</strong>：  <ul>
<li><strong>混合搜索 (Hybrid Search)</strong>：将捕捉语义相似性的向量搜索与捕捉精确匹配的传统关键词搜索相结合。这种方法在处理包含特定术语（如产品型号、专有名词、医疗术语）的查询时尤为有效，因为它兼顾了“意思相近”和“字面相同”两种情况 18。  </li>
<li><strong>重排序 (Re-ranking)</strong>：在检索到初步的文档列表后，使用一个计算更密集、能力更强的“重排序模型”（通常是交叉编码器 Cross-Encoder）对这个列表进行二次排序，以确保最相关的文档排在最前面。这相当于在将上下文交给昂贵的 LLM 之前，进行了一次精细的“提纯”，显著提高了信噪比 18。  </li>
<li><strong>查询转换 (Query Transformations)</strong>：在进行检索之前，先对用户的原始查询进行优化。常见技术包括：<strong>查询扩展</strong>（为查询补充同义词或相关术语）、<strong>查询分解</strong>（将一个复杂问题拆解成多个可以独立检索的子问题），以及<strong>后退提示</strong>（Step-back Prompting，即先生成一个更宽泛、更抽象的问题来获取宏观背景知识，再结合原始问题的细节进行精确检索）23。  </li>
</ul>
</li>
<li>
<strong>高级数据处理与分块</strong>：  <ul>
<li>如何将长文档切分成合适的“块”是 RAG 性能的关键。<strong>语义分块</strong>（Semantic Chunking）技术，即根据文本的语义连贯性而非固定的字符数来切分，能产生更具内在逻辑的文本块。此外，为<strong>句子的滑动窗口</strong>（sliding windows of sentences）创建嵌入，也能更好地保留句子间的上下文联系 23。  </li>
</ul>
</li>
<li>
<strong>GraphRAG：融合结构化知识</strong>：  <ul>
<li>对于需要多步推理的复杂问题（multi-hop questions），将知识以图谱（由实体和关系组成）的形式进行组织，其效果远胜于非结构化的纯文本。<strong>GraphRAG</strong> 技术通过从知识图谱中检索相关的子图，并将其中的结构化信息与传统的向量检索结果相结合，为 LLM 提供了更丰富、更具关联性的上下文 19。LinkedIn 将历史支持工单构建成知识图谱用于客服问答，便是一个成功的商业实例 16。</li>
</ul>
</li>
</ul>
<h3><strong>2.3 Agentic 架构与工具使用</strong></h3>
<p>上下文工程是构建高效 AI 代理（Agent）的基石。一个 AI 代理不仅仅是一个聊天机器人，它是一个能够进行推理、规划并使用外部工具来达成目标的智能系统 29。</p>
<ul>
<li><strong>函数调用 (Function Calling) 作为上下文工具</strong>：函数调用是 LLM 与外部世界（如 API、数据库、代码执行环境）交互的核心机制 32。在实践中，开发者会将一系列可用工具（以函数的形式）的描述作为上下文提供给 LLM。LLM 在理解用户意图后，能够自行判断是否需要以及何时调用某个工具，并以结构化格式（通常是 JSON）生成调用该函数所需的参数 32。这是实现 Agentic RAG 的关键一环，使得 AI 代理能从一个被动的信息整合者，转变为一个主动的任务执行者 30。  </li>
<li>
<strong>单代理 vs. 多代理架构之辩</strong>：  <ul>
<li>一个流行的构想是构建一个由多个专职代理组成的“团队”，让它们协作完成复杂任务。然而，目前的行业实践表明，这种多代理架构往往非常脆弱 11。其根本原因在于，在多个代理之间高效、无损地共享和同步上下文是一个巨大的技术挑战。缺乏共享的上下文会导致决策冲突和工作成果的不连贯 11。  </li>
<li>相比之下，一种更稳健、更可靠的架构是<strong>单线程线性代理</strong>（single-threaded linear agent）。在这种架构中，上下文在任务的每一步中都是连续且共享的，从而避免了因代理间沟通不畅而导致的“滚雪球式”的错误累积 11。这一争论凸显了，上下文流的管理已经成为 AI 应用架构设计的首要考量。</li>
</ul>
</li>
</ul>
<p>在深入探讨这些技术时，一个关键的认知浮出水面：<strong>上下文工程本质上是 AI 时代的数据工程</strong>。整个 RAG 及其高级变体的流水线——从数据抽取、转换、加载（ETL），到数据建模（嵌入）、存储（向量数据库）和查询（检索）——都与传统数据工程的核心任务一一对应 21。企业在实施上下文工程时遇到的最大挑战，如数据质量低下、信息孤岛、治理缺失等 12，也正是数据工程领域长期致力于解决的经典难题 36。这意味着，拥有成熟数据工程文化和实践的组织，在迈向高级 AI 应用的道路上将拥有显著的先发优势。</p>
<p>同时，另一个重要的观点是，<strong>不断增大的“上下文窗口”并非 RAG 的替代品，反而使其变得更为重要</strong>。尽管像 Claude 3 提供的 200k token 上下文窗口看似能让开发者“一股脑”地塞入大量信息 37，但实践和研究均表明，模型在处理超长上下文时存在“迷失在中间”（lost in the middle）的问题，即对输入序列中部信息的注意力会显著下降 15。此外，处理长上下文也意味着更高的 API 调用成本和更长的响应延迟 14。因此，RAG 扮演了一个至关重要的“智能预处理器”角色。与其将海量无关信息全部填入昂贵的上下文窗口，远不如先用廉价高效的检索技术，从海量文档中精确定位出最相关的几个段落。RAG 与大上下文窗口是互补的：RAG 负责决定</p>
<p><strong>什么</strong>信息值得被放入宝贵的上下文窗口中。</p>
<p><strong>表 2：生产级 RAG 系统的关键组件</strong></p>
<table>
<thead>
<tr>
<th align="left">组件</th>
<th align="left">目的</th>
<th align="left">关键技术/工具</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"><strong>数据注入 (Data Ingestion)</strong></td>
<td align="left">从不同来源获取并准备外部知识。</td>
<td align="left">API 连接器、数据库连接器、网络爬虫、ETL 脚本。</td>
</tr>
<tr>
<td align="left"><strong>分块策略 (Chunking Strategy)</strong></td>
<td align="left">将文档分解为大小适中且语义连贯的信息块。</td>
<td align="left">语义分块、句子滑动窗口、基于命题的分块 (Proposition-based chunking)。</td>
</tr>
<tr>
<td align="left"><strong>嵌入模型 (Embedding Model)</strong></td>
<td align="left">将文本块转换为能够捕捉语义的向量。</td>
<td align="left">Sentence-Transformers, OpenAI Embeddings, Cohere Embeddings, 多模态模型。</td>
</tr>
<tr>
<td align="left"><strong>向量存储 (Vector Store)</strong></td>
<td align="left">高效地存储、索引和查询海量向量。</td>
<td align="left">向量数据库 (如 Pinecone, Weaviate, Milvus), Vertex AI Search, Elasticsearch。</td>
</tr>
<tr>
<td align="left"><strong>检索逻辑 (Retrieval Logic)</strong></td>
<td align="left">根据用户查询，找出最相关的上下文信息。</td>
<td align="left">向量搜索、关键词搜索、混合搜索、查询转换 (如 HyDE)。</td>
</tr>
<tr>
<td align="left"><strong>重排序模型 (Re-ranking Model)</strong></td>
<td align="left">对初步检索结果进行二次精排，提升相关性。</td>
<td align="left">交叉编码器 (Cross-Encoders)、基于 LLM 的评估 (LLM-as-a-judge)。</td>
</tr>
<tr>
<td align="left"><strong>生成模型 (Generator LLM)</strong></td>
<td align="left">基于增强后的提示，综合信息并生成最终答案。</td>
<td align="left">GPT-4, Claude 3, Llama 3, Gemini 1.5 Pro。</td>
</tr>
<tr>
<td align="left"><strong>评估与护栏 (Evaluation &amp; Guardrails)</strong></td>
<td align="left">监控系统性能，确保输出的准确性、安全性与合规性。</td>
<td align="left">LLM-as-a-judge 框架、事实核查管道、输出格式与内容验证。</td>
</tr>
</tbody></table><hr />
<h2><strong>第三部分：上下文工程的实践：案例研究与范例剖析</strong></h2>
<p>理论的价值最终体现在实践中。本节将从抽象的架构讨论转向具体的商业应用，通过剖析行业领先企业的案例，展示上下文工程的原则如何转化为可衡量的商业价值和卓越的用户体验。这些案例揭示了一个共同的趋势：竞争优势正从模型本身转向围绕模型构建的、独特的、高效的上下文生态系统。</p>
<h3><strong>3.1 企业应用：构建由上下文驱动的商业解决方案</strong></h3>
<p>大型企业正在积极利用 RAG 和上下文管理来解决其核心业务中的高价值问题，通过将专有数据转化为 AI 的即时知识，实现降本增效和体验提升。</p>
<ul>
<li>
<strong>案例研究：DoorDash —— 高质量的自动化支持</strong>  <ul>
<li><strong>业务挑战</strong>：为数量庞大的送餐员（“Dashers”）提供快速、准确、一致的自动化支持服务。  </li>
<li><strong>解决方案</strong>：DoorDash 构建了一个复杂的、多组件的 RAG 系统。其核心不仅在于从帮助文档和历史案例中检索信息，更在于其完善的质量控制体系。该体系包括：1) 一个核心的 <strong>RAG 系统</strong>，用于信息检索；2) 一个 <strong>“LLM 护栏”</strong>（LLM Guardrail），实时监控生成内容，确保其准确性并符合公司政策；3) 一个 <strong>“LLM 评判官”</strong>（LLM Judge），用于持续评估系统在相关性、连贯性等多个维度上的表现 16。  </li>
<li><strong>实践启示</strong>：此案例雄辩地证明，一个生产级的上下文工程应用，远不止“检索+生成”这么简单。它是一个包含<strong>检索、生成、评估和监控</strong>的完整闭环生态系统。对质量的持续度量和控制是其成功的关键。  </li>
</ul>
</li>
<li>
<strong>案例研究：LinkedIn —— 用于客户服务的结构化上下文</strong>  <ul>
<li><strong>业务挑战</strong>：面对海量的历史客户服务工单，如何高效地为新的用户问题找到解决方案。  </li>
<li><strong>解决方案</strong>：LinkedIn 认识到，将历史工单视为独立的纯文本文件会丢失大量有价值的关联信息。因此，他们采取了更高级的策略：将这些工单数据构建成一个<strong>知识图谱</strong>（Knowledge Graph），明确地表示出不同问题、解决方案和用户之间的内在联系。其 RAG 系统在响应查询时，会从这个图谱中检索相关的<strong>子图</strong>作为上下文，而不仅仅是文本片段 16。  </li>
<li><strong>量化成果</strong>：这一基于结构化上下文的先进方法，使得 LinkedIn 客服团队的<strong>平均问题解决时间中位数降低了 28.6%</strong> 16。  </li>
<li><strong>实践启示</strong>：在处理具有复杂内部关联的数据域时（如客服、法规、供应链），GraphRAG 等利用结构化上下文的技术，相比简单的文本检索具有压倒性的优势。上下文的“结构”本身就是一种宝贵的信息。  </li>
</ul>
</li>
<li>
<strong>案例研究：Bell —— 可扩展的知识管理</strong>  <ul>
<li><strong>业务挑战</strong>：确保公司员工能够随时访问到最新、最准确的内部政策和流程文档。  </li>
<li><strong>解决方案</strong>：加拿大电信巨头 Bell 公司部署了一套模块化的 RAG 系统。该系统的特点在于其强大的数据注入管道，能够支持对知识库的批量和增量更新，并采用<strong>DevOps 原则</strong>来管理和维护整个系统，将其视为一个标准的软件服务来对待 16。  </li>
<li><strong>实践启示</strong>：此案例强调了上下文<strong>生命周期管理</strong>的重要性。上下文不是一次性的构建，而是一个需要持续维护、更新和迭代的动态资产。将其纳入成熟的软件工程管理流程是保证其长期价值的前提。</li>
</ul>
</li>
</ul>
<h3><strong>3.2 “答案引擎”范式：Perplexity AI 深度剖析</strong></h3>
<p>如果说上述案例展示了上下文工程在企业内部的应用，那么 Perplexity AI 则完美诠释了如何将这些原则应用于一个面向公众的、革命性的产品。它不是传统的搜索引擎，也不是简单的聊天机器人，而是一个被业界称为“答案引擎”（Answer Engine）的新物种，是上下文工程理念的集大成者。</p>
<ul>
<li><strong>核心功能</strong>：Perplexity 的工作模式是 RAG 在全网范围内的宏大应用。它接收用户的自然语言问题，通过<strong>实时网络搜索</strong>来收集信息，然后利用 LLM 将检索到的信息综合、提炼成一个直接、连贯、有来源引用的回答，而非仅仅罗列一堆链接 39。  </li>
<li>
<strong>Perplexity AI 中的上下文工程实践</strong>：  <ul>
<li><strong>实时检索作为上下文</strong>：与依赖静态训练数据的 LLM 不同，Perplexity 的核心竞争力在于其为每个问题动态构建上下文的能力。它会实时访问网络，确保提供给 LLM 的信息是最新鲜的 40。  </li>
<li><strong>对话记忆与上下文保持</strong>：Perplexity 通过“线程”（Threads）的概念来管理对话历史。在同一个线程中，用户可以不断追问，而模型会记住之前的对话内容，无需用户重复提供背景信息。这是一种高效的会话级上下文管理机制 39。  </li>
<li><strong>来源追溯与事实接地</strong>：这是 RAG 的标志性优势。Perplexity 生成的每一个关键信息点都会附上来源引用，用户可以轻松点击链接，核实原始出处。这极大地增强了答案的可信度，是建立用户信任的关键 39。  </li>
<li><strong>用户自定义上下文</strong>：平台允许用户上传自己的文档（如 PDF）或图片，将其作为私有知识源纳入到当次查询的上下文中 42。其 API 甚至提供了<br />
search_context_size 这样的参数，让开发者可以根据成本和性能需求，精细地控制从网络检索的上下文数量 38。  </li>
<li><strong>基于上下文的查询理解</strong>：Perplexity 不仅检索上下文，还利用 LLM 来深刻理解用户的查询意图，超越了简单的关键词匹配。其“专业搜索”（Pro Search）模式甚至会主动向用户提出澄清性问题，以进一步精确化上下文的构建 39。</li>
</ul>
</li>
</ul>
<p>这些案例共同揭示了一个深刻的行业趋势：AI 应用的价值核心正在发生转移。随着强大的基础模型日益商品化，通过 API 即可轻松调用，拥有一个略胜一筹的模型本身已不再构成坚固的护城河。真正的、可持续的竞争优势，来源于企业所拥有的独特的、专有的数据，以及更重要的——将这些数据高效、可靠地<strong>工程化为 AI 可用上下文</strong>的能力。DoorDash 的护城河是其精细的知识库和评估体系，LinkedIn 的护城河是其结构化的工单知识图谱，Perplexity 的护城河是其大规模实时编排网络信息为上下文的能力。未来，AI 领域的竞争将不再是“模型之战”，而是“上下文之战”。</p>
<hr />
<h2><strong>第四部分：人的因素：重新定义 AI 开发者的角色与技能</strong></h2>
<p>从提示工程到上下文工程的范式转移，不仅仅是技术栈的更新，更深刻地重塑了 AI 开发者的角色定位、技能要求以及团队协作模式。当 AI 从一个需要被巧妙“哄骗”的黑箱，变成一个需要被系统性“赋能”的合作伙伴时，对其进行“工程化”的人，其价值和职责也必然随之演变。</p>
<h3><strong>4.1 从提示词工匠到系统架构师：角色的演进</strong></h3>
<p>开发者的工作重心正在从“局部”转向“全局”。过去，人们津津乐道的是如何通过遣词造句的“微操”来获得惊艳的单次输出；而现在，真正的挑战在于如何设计一个稳健的系统，使其在面对成千上万次不同的输入时，依然能保持高质量和高可靠性。</p>
<p>这种转变意味着，AI 开发者的角色正在从一个<strong>提示词工匠</strong>（Prompt Crafter）演变为一个<strong>系统架构师</strong>（Systems Architect）3。最有价值的工程师，不再是那个能写出最精妙提示或最多代码的人，而是那个能够最清晰地向 AI 系统</p>
<p><strong>阐明项目需求、架构约束和领域规则</strong>的人。这种能力，被一些从业者称为“上下文阐明”（Context Articulation），已成为新的核心竞争力 29。在这个新范式下，开发者更像是一位集导演、编剧和舞台监督于一身的创作者，负责为 AI 这个“演员”准备好它登台所需的一切：剧本（任务目标）、场景（数据环境）、道具（工具集）和与其他演员的互动规则（协作流程）3。或者，用另一个比喻来说，人类专家是提供方向和智慧的“蜂后”，而 AI 是勤奋执行的“工蜂”，上下文工程则是连接二者、使其高效协作的“蜂巢”架构 44。</p>
<h3><strong>4.2 上下文工程师的新兴技能栈</strong></h3>
<p>要胜任这一新角色，开发者需要一套融合了传统软件工程、数据工程和对 AI 深刻理解的复合型技能。</p>
<ul>
<li>
<strong>核心技术能力</strong>：  <ul>
<li><strong>数据管道与 ETL</strong>：由于上下文工程的核心是为 LLM 准备数据，因此，熟练构建和管理从各种数据源（API、数据库、文档库）抽取、转换和加载数据的管道，成为了基础中的基础。  </li>
<li><strong>信息检索与搜索技术</strong>：必须深入理解向量数据库的原理、嵌入模型的选择与使用，并掌握混合搜索、重排序等高级检索策略，以确保检索到的上下文既相关又精确。  </li>
<li><strong>系统设计与 Agentic 框架</strong>：需要具备设计可扩展、高可用的分布式系统的能力，特别是涉及 Agentic 框架和函数调用（Tool Use）的复杂系统。这要求开发者思考状态管理、任务编排和错误处理等问题。  </li>
<li><strong>评估、测试与可观测性</strong>：这是从“手艺”迈向“工程”的关键。开发者需要为 RAG 系统的输出质量（如相关性、事实一致性）建立量化评估体系，并将提示词和上下文配置视为代码的一部分，对其进行版本控制、单元测试和持续集成 14。  </li>
</ul>
</li>
<li>
<strong>战略与软性技能</strong>：  <ul>
<li><strong>上下文阐明 (Context Articulation)</strong>：如前所述，这是将模糊的业务需求和复杂的领域知识，转化为 AI 能够理解和执行的结构化上下文的能力 29。  </li>
<li><strong>问题建模 (Problem Formulation)</strong>：成功的关键往往在于对问题本身的深刻定义，而非对提示词的反复修改。开发者需要将重心前移，与业务方一起明确问题的范围、边界和成功标准 7。  </li>
<li><strong>跨职能协作</strong>：上下文工程绝非一人之功，它是一项“团队运动”。它要求 AI 开发者与数据工程师、领域专家、产品经理甚至法务与合规团队紧密合作，才能构建出完整、准确的上下文视图 12。</li>
</ul>
</li>
</ul>
<h3><strong>4.3 企业的挑战：驯服碎片化的知识</strong></h3>
<p>对于大型组织而言，实施上下文工程的最大障碍，往往不是技术选型，而是其内部知识管理的现状，即“上下文的混乱”（Context Chaos）12。</p>
<ul>
<li><strong>问题的根源</strong>：企业的关键知识资产通常是<strong>碎片化</strong>的，散落在数十个不同的系统里（如 Jira、Confluence、SharePoint、Slack、CRM 等）；这些知识往往是<strong>不一致</strong>的，同一个概念（如“活跃用户”）在不同部门有不同的定义；它们是<strong>不可信</strong>的，充满了过时信息、手动覆盖和重复逻辑；并且<strong>缺乏明确的所有权</strong>，当 AI 需要一个权威解释时，无人能提供最终答案 12。  </li>
<li>
<strong>解决方案：一种社会技术工程</strong>：解决这个问题，需要超越纯粹的技术视角，将其视为一个社会技术系统工程。这要求企业采取一套组合拳：  <ol>
<li><strong>绘制上下文地图</strong>：首先，需要系统性地盘点和梳理组织内最关键的知识资产，识别其位置、依赖关系和质量状况。  </li>
<li><strong>建立治理体系</strong>：为关键的上下文数据明确所有者、制定标准和访问策略，将其作为一种受管理的核心资产来对待。  </li>
<li><strong>先联邦，后整合</strong>：不要试图一蹴而就地建立一个完美的、集中的“上下文中心”。更务实的做法是，先通过技术手段实现对现有分散系统的<strong>联邦式访问</strong>，然后根据业务价值，逐步将最核心、最通用的上下文层（如核心业务指标定义、组织架构、产品分类等）进行整合 12。</li>
</ol>
</li>
</ul>
<p>这一系列挑战和应对策略，催生了一个关键角色的复兴和升级：<strong>知识工程师 (Knowledge Engineer)</strong>。在上下文工程的时代，知识工程师的角色变得至关重要。他们是连接业务、数据和 AI 的桥梁，其核心职责不再是为传统的专家系统构建规则，而是系统性地捕获、建模、组织和治理企业的知识，最终将其转化为 AI 可以消费的、高质量的上下文 36。他们需要深入理解数据的“5W1H”（Who, What, Where, When, Why, How）36，并利用知识图谱等技术，为企业构建一个可信的、可供 AI 查询的“数字孪生大脑”。这个角色的崛起，标志着企业对“上下文”这一无形资产的战略重视已提升到新的高度。</p>
<p><strong>表 3：AI 应用开发者技能演进趋势</strong></p>
<table>
<thead>
<tr>
<th align="left">技能类别</th>
<th align="left">相对重要性下降 (或成为基础门槛)</th>
<th align="left">相对重要性上升 (新前沿)</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"><strong>模型交互</strong></td>
<td align="left">手工雕琢单个提示词、探索“越狱”技巧。</td>
<td align="left">系统化的提示模板管理、版本控制、自动化评估。</td>
</tr>
<tr>
<td align="left"><strong>数据处理</strong></td>
<td align="left">使用他人预处理好的数据集。</td>
<td align="left">构建稳健的数据注入、清洗、分块和更新管道。</td>
</tr>
<tr>
<td align="left"><strong>系统架构</strong></td>
<td align="left">开发简单的、单轮交互的应用。</td>
<td align="left">设计复杂的多步骤、多工具的 Agentic 系统。</td>
</tr>
<tr>
<td align="left"><strong>核心知识</strong></td>
<td align="left">掌握特定模型的“怪癖”和技巧。</td>
<td align="left">掌握信息检索、数据建模、系统设计等基本原理。</td>
</tr>
<tr>
<td align="left"><strong>团队协作</strong></td>
<td align="left">在开发团队内部协作。</td>
<td align="left">领导跨职能团队，与领域专家、数据、法务等部门协作。</td>
</tr>
</tbody></table><hr />
<h2><strong>第五部分：战略展望与建议</strong></h2>
<p>随着上下文工程从一个新兴概念迅速成为构建高级 AI 应用的行业标准，我们有必要站在一个更宏观的视角，审视其长远影响，并为身处其中的开发者和技术领导者提供战略性的指引。</p>
<h3><strong>5.1 未来是上下文感知的：为何上下文是新的竞争护城河</strong></h3>
<p>在可预见的未来，随着顶级的大型语言模型在能力上趋于同质化，并作为一种基础设施通过 API 广泛可用，竞争的焦点将发生决定性的转移。构建差异化和防御性壁垒的关键，将不再是拥有一个参数量更大或在某个基准上得分稍高的<strong>模型</strong>，而是企业所拥有的独特的、专有的<strong>数据</strong>，以及更重要的——将这些数据<strong>工程化为高质量上下文</strong>的能力 12。</p>
<p>AI 应用的质量上限，将不再由 LLM 的“智商”决定，而将由我们能为其提供的上下文的质量、新鲜度和相关性所决定。一句在开发者圈中广为流传的话精辟地总结了这一点：“上帝渴望上下文”（God is hungry for context）45。未来，那些能够最好地“喂养”AI 的组织，将释放出其最强大的生产力。上下文，而非模型本身，正在成为新的、最坚固的竞争护城河。</p>
<h3><strong>5.2 “上下文工程”只是一个新潮的术语吗？</strong></h3>
<p>面对任何一个新兴术语，一个合理的质疑是：它是否仅仅是对已有概念的重新包装？</p>
<p>对此，我们的分析认为，尽管上下文工程的许多底层原则确实借鉴了信息科学、知识管理、数据工程和认知系统工程等领域数十年的研究成果 36，但将其应用于大型语言模型这一独特的、概率性的、非结构化信息处理的新范式时，它催生出了一门真正独特的、综合性的新工程学科。</p>
<p>这个术语之所以有价值，因为它精准地捕捉到了当前阶段的核心挑战：如何系统性地将人类积累的、往往是混乱且隐性的知识，结构化地、动态地呈现给一个强大的、但不具备人类常识和真实世界经验的非人类智能体。它不是任何一个旧有学科的简单延伸，而是多个学科在一个全新问题域下的交叉、融合与升华。因此，“上下文工程”是一个有用且准确的描述符，它为这个新兴领域提供了清晰的身份认同和发展方向。</p>
<h3><strong>5.3 对开发者与技术领导者的建议</strong></h3>
<p>为了在上下文工程的时代保持领先，从业者和决策者需要主动调整其战略和行动。</p>
<ul>
<li>
<strong>对个人开发者的建议</strong>：  <ol>
<li><strong>像数据工程师一样思考</strong>：投入时间学习数据管道技术（如 Airflow, dbt）、数据建模和信息检索的核心原理。将自己视为一个为 AI 消费端构建数据产品的人。  </li>
<li><strong>拥抱系统思维</strong>：将视野从优化单个提示或函数，提升到设计整个信息流架构的高度。关注系统的可靠性、可观测性和可扩展性。  </li>
<li><strong>将上下文视为代码</strong>：为你构建的上下文管道（包括提示模板、RAG 配置等）引入严格的软件工程实践，包括版本控制（如 Git）、自动化测试和持续评估 15。  </li>
</ol>
</li>
<li>
<strong>对技术领导者的建议</strong>：  <ol>
<li><strong>投资“上下文层”</strong>：将数据治理和构建统一、可信的“上下文层”提升到企业核心战略的高度，而非仅仅是某个项目的技术实现细节。它是未来所有 AI 应用的基石。  </li>
<li><strong>重塑角色与团队</strong>：打破部门墙，积极组建由领域专家、数据工程师和 AI 开发者构成的跨职能“上下文团队”。认真考虑设立专门的“知识工程”职能，负责企业知识资产的梳理与管理 12。  </li>
<li><strong>以评估为导向</strong>：建立并投资于强大的评估框架，用以持续、量化地度量上下文驱动的 AI 系统的性能、准确性和商业价值。没有度量，就没有工程 14。</li>
</ol>
</li>
</ul>
<p>最终，上下文工程的成熟将引领我们走向一个“<strong>隐形提示</strong>”（Invisible Prompt）的未来。当一个 AI 系统能够通过其背后的、强大的上下文工程能力，自动感知用户所处的环境（例如，用户正在查看的屏幕、正在编辑的文档、其在组织中的角色），并主动预测其需求、检索所需信息时，用户与 AI 的交互将变得前所未有的自然和无缝。届时，用户可能只需说一句“这里情况如何？”或者点击一个按钮，而不再需要费力地组织长篇大论的提示。</p>
<p>所有复杂的“工程”工作都将退居幕后，为用户创造出一种仿佛“心有灵犀”的魔法般体验。而支撑这种魔法的，正是本报告所深入探讨的——严谨、系统、且至关重要的上下文工程。</p>
<h4><strong>引用的著作</strong></h4>
<ol>
<li>Karpathy: &quot;context engineering&quot; over &quot;prompt engineering&quot; | Hacker ..., 访问时间为 六月 26, 2025， <a href="https://news.ycombinator.com/item?id=44379538">https://news.ycombinator.com/item?id=44379538</a>  </li>
<li>访问时间为 一月 1, 1970， <a href="https://twitter.com/karpathy/status/1937902205765607626">https://twitter.com/karpathy/status/1937902205765607626</a>  </li>
<li>What is Context Engineering? The new Vibe Coding | by Mehul Gupta | Data Science in Your Pocket - Medium, 访问时间为 六月 26, 2025， <a href="https://medium.com/data-science-in-your-pocket/what-is-context-engineering-the-new-vibe-coding-8d04421b6a11">https://medium.com/data-science-in-your-pocket/what-is-context-engineering-the-new-vibe-coding-8d04421b6a11</a>  </li>
<li>AI | Dan Calle, 访问时间为 六月 26, 2025， <a href="http://dancalle.com/tag/ai/">http://dancalle.com/tag/ai/</a>  </li>
<li>AI Context Engineering: Key Questions to Ask | TikTok, 访问时间为 六月 26, 2025， <a href="https://www.tiktok.com/@nate.b.jones/video/7518121865790131486">https://www.tiktok.com/@nate.b.jones/video/7518121865790131486</a>  </li>
<li>medium.com, 访问时间为 六月 26, 2025， <a href="https://medium.com/@manish434k/i-am-choosing-context-engineering-over-prompt-engineering-7b4a10250e0b#:~:text=Prompt%20engineering%20primarily%20refers%20to,prompt%20to%20give%20precise%20output.">https://medium.com/@manish434k/i-am-choosing-context-engineering-over-prompt-engineering-7b4a10250e0b#:~:text=Prompt%20engineering%20primarily%20refers%20to,prompt%20to%20give%20precise%20output.</a>  </li>
<li>Effective Prompts for AI: The Essentials - MIT Sloan Teaching &amp; Learning Technologies, 访问时间为 六月 26, 2025， <a href="https://mitsloanedtech.mit.edu/ai/basics/effective-prompts/">https://mitsloanedtech.mit.edu/ai/basics/effective-prompts/</a>  </li>
<li>Understanding Prompting, Prompt Engineering and In-Context Learning in LLMs - Medium, 访问时间为 六月 26, 2025， <a href="https://medium.com/codex/understanding-prompting-prompt-engineering-and-in-context-learning-in-llms-2b59fb398fef">https://medium.com/codex/understanding-prompting-prompt-engineering-and-in-context-learning-in-llms-2b59fb398fef</a>  </li>
<li>I am Choosing 'Context Engineering' over 'Prompt Engineering'! | by ..., 访问时间为 六月 26, 2025， <a href="https://medium.com/@manish434k/i-am-choosing-context-engineering-over-prompt-engineering-7b4a10250e0b">https://medium.com/@manish434k/i-am-choosing-context-engineering-over-prompt-engineering-7b4a10250e0b</a>  </li>
<li>Prompt engineering will be obsolete? : r/PromptEngineering - Reddit, 访问时间为 六月 26, 2025， <a href="https://www.reddit.com/r/PromptEngineering/comments/1ldgn7t/prompt_engineering_will_be_obsolete/">https://www.reddit.com/r/PromptEngineering/comments/1ldgn7t/prompt_engineering_will_be_obsolete/</a>  </li>
<li>Don't Build Multi-Agents - Cognition, 访问时间为 六月 26, 2025， <a href="https://cognition.ai/blog/dont-build-multi-agents">https://cognition.ai/blog/dont-build-multi-agents</a>  </li>
<li>Beyond Prompts: The Rise of Context Engineering​​ | by Nileshk | Jun, 2025 | Medium, 访问时间为 六月 26, 2025， <a href="https://medium.com/@nileshk77487/beyond-prompts-the-rise-of-context-engineering-06050a5d59b6">https://medium.com/@nileshk77487/beyond-prompts-the-rise-of-context-engineering-06050a5d59b6</a>  </li>
<li>The rise of &quot;context engineering&quot; - LangChain Blog, 访问时间为 六月 26, 2025， <a href="https://blog.langchain.com/the-rise-of-context-engineering/">https://blog.langchain.com/the-rise-of-context-engineering/</a>  </li>
<li>What Actually Matters When You Scale? : r/aipromptprogramming - Reddit, 访问时间为 六月 26, 2025， <a href="https://www.reddit.com/r/aipromptprogramming/comments/1l732wf/what_actually_matters_when_you_scale/">https://www.reddit.com/r/aipromptprogramming/comments/1l732wf/what_actually_matters_when_you_scale/</a>  </li>
<li>Stop Prompting, Start Engineering: 15 Principles to Deliver Your AI Agent to Production, 访问时间为 六月 26, 2025， <a href="https://hackernoon.com/stop-prompting-start-engineering-15-principles-to-deliver-your-ai-agent-to-production">https://hackernoon.com/stop-prompting-start-engineering-15-principles-to-deliver-your-ai-agent-to-production</a>  </li>
<li>10 RAG examples and use cases from real companies - Evidently AI, 访问时间为 六月 26, 2025， <a href="https://www.evidentlyai.com/blog/rag-examples">https://www.evidentlyai.com/blog/rag-examples</a>  </li>
<li>cloud.google.com, 访问时间为 六月 26, 2025， <a href="https://cloud.google.com/use-cases/retrieval-augmented-generation#:~:text=RAG%20(Retrieval%2DAugmented%20Generation),large%20language%20models%20(LLMs).">https://cloud.google.com/use-cases/retrieval-augmented-generation#:~:text=RAG%20(Retrieval%2DAugmented%20Generation),large%20language%20models%20(LLMs).</a>  </li>
<li>What is Retrieval-Augmented Generation (RAG)? | Google Cloud, 访问时间为 六月 26, 2025， <a href="https://cloud.google.com/use-cases/retrieval-augmented-generation">https://cloud.google.com/use-cases/retrieval-augmented-generation</a>  </li>
<li>Retrieval-augmented generation - Wikipedia, 访问时间为 六月 26, 2025， <a href="https://en.wikipedia.org/wiki/Retrieval-augmented_generation">https://en.wikipedia.org/wiki/Retrieval-augmented_generation</a>  </li>
<li>What is Retrieval Augmented Generation (RAG)? - Databricks, 访问时间为 六月 26, 2025， <a href="https://www.databricks.com/glossary/retrieval-augmented-generation-rag">https://www.databricks.com/glossary/retrieval-augmented-generation-rag</a>  </li>
<li>What is RAG? - Retrieval-Augmented Generation AI Explained - AWS, 访问时间为 六月 26, 2025， <a href="https://aws.amazon.com/what-is/retrieval-augmented-generation/">https://aws.amazon.com/what-is/retrieval-augmented-generation/</a>  </li>
<li>What is retrieval-augmented generation (RAG)? - McKinsey, 访问时间为 六月 26, 2025， <a href="https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-is-retrieval-augmented-generation-rag">https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-is-retrieval-augmented-generation-rag</a>  </li>
<li>Advanced RAG Techniques - Guillaume Laforge, 访问时间为 六月 26, 2025， <a href="https://glaforge.dev/talks/2024/10/14/advanced-rag-techniques/">https://glaforge.dev/talks/2024/10/14/advanced-rag-techniques/</a>  </li>
<li>Advanced RAG Techniques - Cazton, 访问时间为 六月 26, 2025， <a href="https://www.cazton.com/blogs/technical/advanced-rag-techniques">https://www.cazton.com/blogs/technical/advanced-rag-techniques</a>  </li>
<li>Retrieval Augmented Generation use cases for enterprise - Indigo.ai, 访问时间为 六月 26, 2025， <a href="https://indigo.ai/en/blog/retrieval-augmented-generation/">https://indigo.ai/en/blog/retrieval-augmented-generation/</a>  </li>
<li>Advanced RAG Techniques - DataCamp, 访问时间为 六月 26, 2025， <a href="https://www.datacamp.com/blog/rag-advanced">https://www.datacamp.com/blog/rag-advanced</a>  </li>
<li>Advanced RAG Techniques - Weaviate, 访问时间为 六月 26, 2025， <a href="https://weaviate.io/blog/advanced-rag">https://weaviate.io/blog/advanced-rag</a>  </li>
<li>NirDiamant/RAG_Techniques: This repository showcases various advanced techniques for Retrieval-Augmented Generation (RAG) systems. RAG systems combine information retrieval with generative models to provide accurate and contextually rich responses. - GitHub, 访问时间为 六月 26, 2025， <a href="https://github.com/NirDiamant/RAG_Techniques">https://github.com/NirDiamant/RAG_Techniques</a>  </li>
<li>The Human-AI Partnership: Redefining Developer Roles in the Age of Autonomous Coding Agents - Zencoder, 访问时间为 六月 26, 2025， <a href="https://zencoder.ai/blog/human-ai-partnership-redefining-developer-roles">https://zencoder.ai/blog/human-ai-partnership-redefining-developer-roles</a>  </li>
<li>Function Calling with Open-Source LLMs - BentoML, 访问时间为 六月 26, 2025， <a href="https://bentoml.com/blog/function-calling-with-open-source-llms">https://bentoml.com/blog/function-calling-with-open-source-llms</a>  </li>
<li>LLM Agent vs Function Calling: Key Differences &amp; Use Cases - PromptLayer, 访问时间为 六月 26, 2025， <a href="https://blog.promptlayer.com/llm-agents-vs-function-calling/">https://blog.promptlayer.com/llm-agents-vs-function-calling/</a>  </li>
<li>Function Calling with LLMs - Prompt Engineering Guide, 访问时间为 六月 26, 2025， <a href="https://www.promptingguide.ai/applications/function_calling">https://www.promptingguide.ai/applications/function_calling</a>  </li>
<li>Function Calling in LLMs – Real Use Cases and Value? : r/AI_Agents - Reddit, 访问时间为 六月 26, 2025， <a href="https://www.reddit.com/r/AI_Agents/comments/1iio39z/function_calling_in_llms_real_use_cases_and_value/">https://www.reddit.com/r/AI_Agents/comments/1iio39z/function_calling_in_llms_real_use_cases_and_value/</a>  </li>
<li>Function calling - OpenAI API, 访问时间为 六月 26, 2025， <a href="https://platform.openai.com/docs/guides/function-calling">https://platform.openai.com/docs/guides/function-calling</a>  </li>
<li>GPT-5 coming this summer- Weekly AI Newsletter (June 23rd 2025) - Medium, 访问时间为 六月 26, 2025， <a href="https://medium.com/nlplanet/gpt-5-coming-this-summer-weekly-ai-newsletter-june-23rd-2025-7c539b073b09">https://medium.com/nlplanet/gpt-5-coming-this-summer-weekly-ai-newsletter-june-23rd-2025-7c539b073b09</a>  </li>
<li>Data in the generative AI era: We need more knowledge engineers - SiliconANGLE, 访问时间为 六月 26, 2025， <a href="https://siliconangle.com/2025/02/04/data-generative-ai-era-need-knowledge-engineers/">https://siliconangle.com/2025/02/04/data-generative-ai-era-need-knowledge-engineers/</a>  </li>
<li>Advanced RAG: Best Practices for Production Ready Systems, 访问时间为 六月 26, 2025， <a href="https://www.getsubatomic.ai/blog-posts/advanced-rag">https://www.getsubatomic.ai/blog-posts/advanced-rag</a>  </li>
<li>Search Context Size - Perplexity, 访问时间为 六月 26, 2025， <a href="https://docs.perplexity.ai/guides/search-context-size-guide">https://docs.perplexity.ai/guides/search-context-size-guide</a>  </li>
<li>Perplexity AI and Its Impact on Search Engines - SmythOS, 访问时间为 六月 26, 2025， <a href="https://smythos.com/ai-agents/ai-tutorials/perplexity-ai/">https://smythos.com/ai-agents/ai-tutorials/perplexity-ai/</a>  </li>
<li>How does Perplexity work? | Perplexity Help Center, 访问时间为 六月 26, 2025， <a href="https://www.perplexity.ai/help-center/en/articles/10352895-how-does-perplexity-work">https://www.perplexity.ai/help-center/en/articles/10352895-how-does-perplexity-work</a>  </li>
<li>What Makes Perplexity AI a Revolutionary Search Engine? - Pageon.ai, 访问时间为 六月 26, 2025， <a href="https://www.pageon.ai/blog/perplexity-ai-search-engine-08u7f">https://www.pageon.ai/blog/perplexity-ai-search-engine-08u7f</a>  </li>
<li>What is Perplexity AI? How to use it + how it works - Zapier, 访问时间为 六月 26, 2025， <a href="https://zapier.com/blog/perplexity-ai/">https://zapier.com/blog/perplexity-ai/</a>  </li>
<li>Perplexity AI Review: How the AI Search Engine Works? | WPS Office Blog, 访问时间为 六月 26, 2025， <a href="https://www.wps.ai/blog/perplexity-ai-review-how-the-ai-search-engine-works/">https://www.wps.ai/blog/perplexity-ai-review-how-the-ai-search-engine-works/</a>  </li>
<li>Context Engineering and Domain Expertise in Generative AI-Powered Software Development - My Framer Site - XponentL Data, 访问时间为 六月 26, 2025， <a href="https://xponentl.ai/news/context-engineering-and-domain-expertise-in-generative-ai-powered-software-development">https://xponentl.ai/news/context-engineering-and-domain-expertise-in-generative-ai-powered-software-development</a>  </li>
<li>Why Context Engineering Matters - YouTube, 访问时间为 六月 26, 2025， <a href="https://www.youtube.com/watch?v=fYgsZnkFeck">https://www.youtube.com/watch?v=fYgsZnkFeck</a>  </li>
<li>1 Introduction and objectives 2 Context and engineering design research issues., 访问时间为 六月 26, 2025， <a href="https://www.designsociety.org/download-publication/24116/A+SURVEY+OF+CONTEXT+MODELING%3A+APPROACHES%2C+THEORIES+AND+USE+FOR+ENGINEERING+DESIGN+RESEARCHES.">https://www.designsociety.org/download-publication/24116/A+SURVEY+OF+CONTEXT+MODELING%3A+APPROACHES%2C+THEORIES+AND+USE+FOR+ENGINEERING+DESIGN+RESEARCHES.</a>  </li>
<li>Characterizing Proof-of-Concept Practices using the Lens of Context Engineering - Estudo Geral, 访问时间为 六月 26, 2025， <a href="https://estudogeral.uc.pt/bitstream/10316/113037/1/Characterizing%20Proof-of-Concept%20Practices%20using%20the%20Lens%20of%20Conte.pdf">https://estudogeral.uc.pt/bitstream/10316/113037/1/Characterizing%20Proof-of-Concept%20Practices%20using%20the%20Lens%20of%20Conte.pdf</a>  </li>
<li>&quot;Relevance, Works and Context Engineering&quot; by Michael K. Buckland and Wayne de Fremery - IdeaExchange@UAkron, 访问时间为 六月 26, 2025， <a href="https://ideaexchange.uakron.edu/docam/vol11/iss2/5/">https://ideaexchange.uakron.edu/docam/vol11/iss2/5/</a>  </li>
<li>SYSTEMS ENGINEERING AND MANAGEMENT DEFINITIONS - Project Performance International (PPI), 访问时间为 六月 26, 2025， <a href="https://www.ppi-int.com/wp-content/uploads/2023/05/PPI-007725-7-SEM-Definitions-221017-SE5D-3.pdf">https://www.ppi-int.com/wp-content/uploads/2023/05/PPI-007725-7-SEM-Definitions-221017-SE5D-3.pdf</a></li>
</ol>
</details>
<hr />
<details>
  <summary>SWE-agent深度解析：从代理-计算机接口到AI驱动软件工程的新前沿 (Gemini Deep Research - 仅供参考)</summary>
<h1><strong>SWE-agent深度解析：从代理-计算机接口到AI驱动软件工程的新前沿</strong></h1>
<h2><strong>第一部分：SWE-agent简介：自动化软件工程的范式转移</strong></h2>
<h3><strong>1.1 定义SWE-agent</strong></h3>
<p>SWE-agent是一个由普林斯顿大学和斯坦福大学的研究人员开发和维护的开源项目 1。它被定义为一个自主系统，旨在赋能大型语言模型（Large Language Model, LM）扮演软件工程代理的角色，通过自主使用工具来解决真实GitHub代码库中的问题 1。该系统的应用范围不仅限于修复软件缺陷（bug fixing），还扩展到了网络安全挑战（如夺旗赛）和编程竞赛等领域 2。作为一个研究导向的工具，SWE-agent的设计理念是“自由流畅且可泛化”，即给予语言模型最大的自主权；同时它也是“可配置且文档齐全的”，其行为主要由一个YAML配置文件控制，并以“简单且易于修改”为设计目标，从而方便学术界进行二次开发和研究 1。</p>
<h3><strong>1.2 核心论点：将大型语言模型视为一类新型终端用户</strong></h3>
<p>SWE-agent项目的核心哲学论点是，大型语言模型代表了一类全新的“终端用户”，它们拥有与人类用户截然不同的需求和能力 4。正如人类开发者受益于集成开发环境（Integrated Development Environments, IDEs）等强大的软件应用来处理复杂的软件工程任务一样，语言模型代理也需要为其量身定制的接口，以便与代码库等复杂的数字环境进行高效交互 4。这一核心思想构成了整个项目的理论基础，并为其最主要的创新——代理-计算机接口（Agent-Computer Interface, ACI）的提出提供了理论依据。</p>
<p>这种观念的转变是深刻的。在此之前，许多系统将代码任务视为一个单向的生成过程：输入一个提示，输出一段代码。然而，软件工程的本质远不止于此，它是一个涉及探索、调试、测试和迭代的复杂过程。SWE-agent的提出，标志着业界开始将软件工程任务重新定义为一个代理与其环境之间的持续、有状态的对话。这种对话的质量，很大程度上取决于两者之间的交互媒介。因此，SWE-agent的真正突破并非仅仅是提出一个更优的模型或提示工程技巧，而是创建了一个全新的交互范式，承认了软件工程的探索性本质，并为语言模型提供了有效参与这一过程的工具和接口。从静态生成到动态交互的飞跃，为后续所有相关研究的进展奠定了基础。</p>
<h3><strong>1.3 初步影响与业界领先（SOTA）性能</strong></h3>
<p>SWE-agent一经发布，便在业界产生了显著影响。它在SWE-bench基准测试上取得了当时最先进（State-of-the-Art, SOTA）的性能，这是一个包含真实世界GitHub问题的挑战性数据集 1。使用GPT-4 Turbo作为后端模型，SWE-agent成功解决了2,294个任务中的12.47%，这一成绩远超此前由非交互式、检索增强系统创下的3.8%的最佳纪录 8。这一突破性成果不仅验证了项目核心论点的正确性，也为整个领域设立了新的性能基准。从其后续发布的新闻来看，SWE-agent持续与多种业界领先模型（如GPT-4o、Claude 3系列）结合，并不断刷新SWE-bench的最高分纪录，甚至推出了性能卓越的开源权重模型SWE-agent-LM-32b，进一步巩固了其在开源项目中的领先地位 1。</p>
<h3><strong>1.4 关键特性</strong></h3>
<p>SWE-agent项目具备几个鲜明的特点，使其在众多AI编码工具中脱颖而出。首先，它具有<strong>自由流畅和高度泛化</strong>的能力，这意味着框架本身不对语言模型的行为做过多限制，从而最大限度地保留了模型的自主决策能力 1。其次，系统具有</p>
<p><strong>高度可配置性</strong>，整个代理的行为逻辑和工具集都通过一个统一的YAML配置文件进行管理，方便用户根据不同任务进行定制 1。最后，该项目</p>
<p><strong>为研究而生</strong>，其代码设计简洁明了，易于修改和扩展（hackable by design），这极大地促进了学术界在此基础上进行进一步的研究和创新 1。</p>
<h2><strong>第二部分：代理-计算机接口（ACI）：SWE-agent的架构基石</strong></h2>
<h3><strong>2.1 ACI概念框架</strong></h3>
<p>代理-计算机接口（Agent-Computer Interface, ACI）是SWE-agent项目的核心创新和架构基石。它被定义为专为大型语言模型代理设计的、用于与计算机进行交互的接口，其核心功能是明确规定代理可用的命令集以及环境反馈的格式 8。ACI的设计理念与传统面向人类用户的界面（如图形用户界面GUI和标准Linux命令行）形成了鲜明对比。GUI富含视觉元素和复杂的工作流，对于纯文本处理的语言模型而言难以解析和导航；而Linux命令行虽然是基于文本的，但其命令通常包含大量选项，输出信息冗长，很容易超出语言模型有限的上下文窗口，从而干扰其对核心任务的专注 9。</p>
<p>因此，ACI的提出是一项深思熟虑的设计决策，其目标是在不修改底层语言模型权重的前提下，通过优化交互接口来显著提升代理的性能 8。ACI的真正功能可以被理解为一个“阻抗匹配”层，它巧妙地连接了两个性质迥异的系统：一个是大型语言模型的概率性、高层次、有时非确定性的推理能力，另一个是计算机文件系统和命令行的确定性、低层次、不容错误的执行环境。</p>
<p>语言模型基于词元（token）和统计规律进行操作，它无法像人类一样真正“理解”文件系统的结构。因此，它很容易生成语法上看似合理但语义上完全错误的命令（例如，为grep命令提供一个不存在的参数）。而计算机的命令行环境则是严格字面的，任何一个微小的错误都会导致命令失败。这种不匹配造成了巨大的“阻抗”：语言模型模糊的输出意图被计算机刚性的输入要求频繁拒绝，导致大量的无效尝试和任务失败。</p>
<p>ACI的设计原则正是为了解决这种不匹配。通过提供“简单的命令”，它减小了语言模型出错的可能性；通过返回“简洁的反馈”，它将计算机的状态高效地翻译成模型可以消化的词元摘要；通过内置“防护栏”，它在接口层面拦截错误，防止其破坏代理的整个任务规划。因此，ACI不仅仅是一套工具，更是一个翻译和缓冲层。它有效地降低了两个系统之间的“阻抗”，使得语言模型的“推理能量”能够顺畅地流入“编码任务”这个系统中，并将过程中的损耗（即错误和无效的交互回合）降至最低。这从根本上解释了为何ACI相比于原始的命令行环境，能够带来如此显著的性能提升。</p>
<h3><strong>2.2 ACI的核心设计原则</strong></h3>
<p>通过对代理行为的手动检查和网格搜索优化，SWE-agent的研究者们提炼出了构建高效ACI的四条核心设计原则 6。</p>
<ol>
<li><strong>动作应简单易懂 (Simple and Easy-to-Understand Actions):</strong> ACI提供的命令应该只有少数几个选项和简洁明了的文档。这使得语言模型更容易正确地使用它们，而无需依赖大量的示例（demonstrations）或复杂的微调。这与许多拥有数十个参数选项的bash命令形成了鲜明对比，后者对模型来说极易产生混淆和误用 6。  </li>
<li><strong>操作应紧凑高效 (Compact and Efficient Operations):</strong> 重要的、高层次的操作（如文件导航和代码编辑）应被整合成尽可能少的动作。高效的动作能帮助代理在单个交互回合内取得实质性进展，避免了为完成一个高阶操作而需要组合多个简单动作、跨越数个回合的低效循环 6。  </li>
<li><strong>环境反馈应信息丰富且简洁 (Informative and Concise Environment Feedback):</strong> ACI必须为代理提供关于当前环境状态及其最近动作效果的、有意义的反馈。反馈内容应高度相关且简洁，避免不必要的冗余信息。例如，当代理编辑一个文件后，ACI会向其展示修改处附近的代码片段，而不是整个文件的内容，这有助于代理理解其修改所带来的影响，同时有效利用宝贵的上下文窗口 6。  </li>
<li><strong>内置防护栏以减少错误传播 (Proactive Guardrails for Error Mitigation):</strong> 与人类一样，语言模型在编辑或搜索时也会犯错，并且往往难以从错误中恢复。ACI通过内置防护栏机制来主动预防常见错误并帮助代理恢复。一个关键例子是集成的代码语法检查器（linter），它可以在代理提交编辑后立即检测出语法错误并返回提示，帮助代理快速识别并纠正问题，从而避免了错误状态的持续传播 6。</li>
</ol>
<h3><strong>2.3 ACI命令套件</strong></h3>
<p>ACI的命令套件是其设计原则的具体体现，它为语言模型提供了一套专门用于软件工程任务的工具。</p>
<ul>
<li><strong>搜索与导航 (Search and Navigation):</strong> 为了解决在大型代码库中定位相关文件和代码片段的难题，ACI引入了find_file、search_file和search_dir等专用命令。这些命令与传统的grep或find不同，它们返回的是经过处理的搜索结果摘要，而非可能淹没上下文窗口的原始输出流，从而极大地简化了信息定位过程 6。  </li>
<li><strong>文件查看器 (File Viewer):</strong> ACI的文件查看器经过精心设计，以适应语言模型的上下文限制。它不会一次性显示整个文件内容，而是提供一个可滚动的代码行“窗口”。代理可以通过滚动指令来查看文件的不同部分，这种聚焦式的方法可以防止代理被大型文件所压垮，确保其有限的上下文窗口被高效利用 11。  </li>
<li><strong>文件编辑器 (File Editor):</strong> 文件编辑是ACI的核心功能之一。它被设计得既简单又健壮，通常以行号或代码块为单位进行操作。更重要的是，它紧密集成了之前提到的防护栏机制，如语法检查。当编辑操作导致语法错误时，系统会立即返回明确的错误信息，指导模型进行修正 8。  </li>
<li><strong>命令执行 (Execution):</strong> SWE-agent构建于Linux命令行之上，因此在需要时仍然可以访问标准的bash命令。然而，ACI为执行测试等关键操作提供了结构化的方式，它能够捕获命令的输出，并将其整理成干净、易于模型解析的格式，从而方便模型对测试结果进行分析和决策 8。</li>
</ul>
<p>下表详细对比了ACI命令与标准Shell命令，以突显ACI为语言模型所做的优化设计。</p>
<p><strong>表2.1: ACI命令套件与标准Shell命令对比</strong></p>
<table>
<thead>
<tr>
<th align="left">ACI 命令/工具</th>
<th align="left">功能及面向LM的设计</th>
<th align="left">可比的Shell命令</th>
<th align="left">ACI优势 (为何对LM更优)</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">search_file / search_dir</td>
<td align="left">在文件或目录中搜索字符串，返回包含匹配项及其行号的简洁摘要。</td>
<td align="left">grep, find</td>
<td align="left">避免冗长的原始输出，提供结构化的反馈，减少了模型混淆复杂命令参数的可能性，专注于核心信息。</td>
</tr>
<tr>
<td align="left">文件编辑器</td>
<td align="left">提供基于行号或代码块的编辑功能，并内置语法检查器，对失败的编辑提供即时、明确的错误反馈。</td>
<td align="left">sed, awk, vim, nano</td>
<td align="left">简化了复杂的流编辑语法，集成了错误检查机制，防止错误状态传播，降低了模型进行有效代码修改的难度。</td>
</tr>
<tr>
<td align="left">文件查看器</td>
<td align="left">提供一个可滚动的代码“窗口”，而不是一次性加载整个文件，并始终显示当前打开的文件和行号。</td>
<td align="left">cat, less, more</td>
<td align="left">节约了宝贵的上下文空间，帮助模型在大型文件中保持定位感，避免因信息过载而“分心”。</td>
</tr>
<tr>
<td align="left">测试执行器</td>
<td align="left">以结构化方式执行测试脚本，捕获并格式化输出，清晰地呈现成功或失败的测试用例。</td>
<td align="left">直接执行 pytest 或其他测试框架</td>
<td align="left">将混乱的测试日志解析为清晰、简洁的摘要，使模型能够轻松判断其代码修改是否解决了问题。</td>
</tr>
</tbody></table><p>数据来源: 6</p>
<h3><strong>2.4 运行机制</strong></h3>
<p>SWE-agent的有效运行依赖于两个关键机制：ReAct框架和上下文管理。</p>
<ul>
<li><strong>ReAct框架:</strong> SWE-agent遵循ReAct（Reasoning and Acting）思想范式。在交互的每一步，语言模型都会生成一个“思考（thought）”和一个“命令（command）”。“思考”是模型对当前状态的分析、推理和下一步计划的阐述，“命令”则是它决定要执行的具体ACI动作 9。这种模式使得代理的决策过程更加透明，也便于分析其行为逻辑。  </li>
<li><strong>上下文管理与历史记录折叠:</strong> 这是ACI一个至关重要但又不易察觉的特性。为了在语言模型有限的上下文窗口内进行长序列的交互，ACI采用了一种“历史记录折叠”的策略。当交互历史过长时，它会将较早的、重要性较低的交互回合（包括命令和环境反馈）折叠成一条占位符消息，例如“之前的15个回合已折叠”。与此同时，最近的几个交互回合则会完整地保留在上下文中。这种机制确保了模型在做决策时，既能感知到最近发生的情况，又不会被过时的信息所干扰，从而在保持任务相关性的同时，显著降低了每次推理的计算成本 12。</li>
</ul>
<h2><strong>第三部分：SWE-bench生态系统：软件工程代理的严苛试炼场</strong></h2>
<h3><strong>3.1 概述与目标</strong></h3>
<p>SWE-bench是用于评估SWE-agent及其同类产品的核心基准测试 13。它并非一个人工合成的数据集，而是完全源于真实世界的软件开发场景。该基准测试从GitHub上12个广受欢迎的Python项目中收集了2,294个“问题-拉取请求”（Issue-Pull Request）配对 13。其核心任务是：给定一个代码库的特定版本和一个用自然语言描述的GitHub Issue，要求AI代理生成一个代码补丁（patch），以解决该Issue中描述的问题 15。这一设定极大地考验了AI代理的代码理解、推理、规划和代码生成能力。</p>
<p>SWE-bench的出现本身就是一次重要的学术贡献，因为它为评估AI软件工程师的能力提供了一个可量化、可复现的平台。但它的意义远不止于一个静态的评分标准。随着研究的深入，SWE-bench自身也在不断演进，其局限性反而成为了催生新一代基准和训练环境的强大动力。</p>
<p>最初的SWE-bench数据集规模庞大，运行一次完整的评估需要耗费大量计算资源，这使得研究人员难以进行快速的迭代和实验。为了解决这个问题，研究团队推出了<strong>SWE-bench Lite</strong>，一个规模更小、更易于管理的子集。当研究人员发现原始数据集中可能存在定义不清或难以解决的问题时，他们与OpenAI合作，通过人工验证的方式创建了<strong>SWE-bench Verified</strong>，确保了基准的高质量和可靠性。随后，为了应对AI代理可能对Python特定工具产生“过拟合”的风险，<strong>SWE-bench Multilingual</strong>应运而生，将评估范围扩展到多种编程语言。而<strong>SWE-bench Multimodal</strong>的出现，则进一步将挑战推向了包含视觉元素的软件领域。</p>
<p>然而，所有这些“bench”系列的数据集都有一个共同的根本性局限：它们只为<strong>评估</strong>而设计。数据集中只包含最终解决问题的代码补丁，却缺失了开发者为了写出这个补丁所经历的、一步一步的试错和探索过程。这一“过程数据”的缺失，使得直接在这些数据集上<strong>训练</strong>一个智能代理变得异常困难。正是这一局限性，直接催化了<strong>SWE-Gym</strong>的诞生。SWE-Gym不再仅仅提供问题和答案，而是提供了一个完整的、可执行的交互环境和奖励信号，从而将研究的重心从“如何评估代理”推向了“如何训练代理”的新阶段。因此，SWE-bench生态系统的发展历程，生动地展示了它如何作为一个活跃的研究催化剂，通过不断暴露自身的不足来持续推动整个领域向前发展。</p>
<h3><strong>3.2 SWE-bench数据集家族</strong></h3>
<p>随着时间的推移，SWE-bench已经从一个单一的数据集发展成为一个包含多个变体的“家族”，每个变体都有其特定的评估目标。</p>
<ul>
<li><strong>SWE-bench (Full):</strong> 这是最初的、最完整的数据集，包含全部2,294个实例，用于进行最全面的性能评估 13。  </li>
<li><strong>SWE-bench Lite:</strong> 这是一个精简的子集，最初包含300个实例，后来扩展到534个。它主要用于快速、低成本的评估和开发测试，其中的任务经过筛选，更侧重于功能性的、相对独立的软件缺陷修复 8。  </li>
<li><strong>SWE-bench Verified:</strong> 这是一个高质量的子集，包含了从测试集中精心挑选的500个实例。这些实例都经过了人类软件工程师的逐一验证，以确保问题描述清晰、任务可解。该数据集是与OpenAI的预备团队（Preparedness team）合作的产物，旨在提高基准测试结果的可靠性和公信力 15。  </li>
<li><strong>SWE-bench Multilingual:</strong> 这是一个多语言版本的数据集，包含来自9种不同编程语言（如C、C++、Go、Java、JavaScript等）的300个任务。它的设计目标是评估AI代理在非Python环境下的泛化能力，并防止研究社区过度拟合Python特有的工具链 19。  </li>
<li><strong>SWE-bench Multimodal:</strong> 这是一个前沿的变体，其任务中包含了截图、UI元素等视觉信息，旨在测试代理在处理涉及图形界面的软件任务时的能力。为了保证排行榜的公平性，其测试集的真实解（ground truth）保持私有，需要通过专门的命令行工具提交结果进行云端评估 15。</li>
</ul>
<p><strong>表3.1: SWE-bench 数据集变体</strong></p>
<table>
<thead>
<tr>
<th align="left">数据集变体</th>
<th align="left">规模</th>
<th align="left">构成与目标</th>
<th align="left">核心贡献</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">SWE-bench</td>
<td align="left">2,294个实例</td>
<td align="left">完整的测试集，用于全面、综合的性能评估。</td>
<td align="left">建立了领域内首个基于真实世界问题的软件工程基准。</td>
</tr>
<tr>
<td align="left">SWE-bench Lite</td>
<td align="left">534个实例</td>
<td align="left">精简的子集，用于快速迭代和开发。</td>
<td align="left">降低了评估成本，加速了研究周期。</td>
</tr>
<tr>
<td align="left">SWE-bench Verified</td>
<td align="left">500个实例</td>
<td align="left">经过人类专家验证的可解问题子集。</td>
<td align="left">提高了评估结果的可靠性和公信力。</td>
</tr>
<tr>
<td align="left">SWE-bench Multilingual</td>
<td align="left">300个实例</td>
<td align="left">包含9种编程语言的任务。</td>
<td align="left">推动了代理的跨语言泛化能力研究，防止了对Python的过拟合。</td>
</tr>
<tr>
<td align="left">SWE-bench Multimodal</td>
<td align="left">100个开发实例，500个测试实例</td>
<td align="left">包含截图等视觉信息的任务。</td>
<td align="left">将评估范围扩展到多模态软件工程领域。</td>
</tr>
</tbody></table><p>数据来源: 13</p>
<h3><strong>3.3 评估协议与可复现性</strong></h3>
<p>SWE-bench生态系统极为重视评估的科学性和严谨性。其评估协议的核心是通过单元测试进行验证，即以问题修复后（post-PR）的代码行为作为黄金标准（ground truth） 13。为了确保评估结果的可复现性，整个评估流程被完全容器化。每个测试实例都在一个独立的Docker容器中运行，该容器预装了项目所需的所有依赖。这种设计确保了无论在何种机器或操作系统上运行评估，都能得到一致的结果，这对于可信的学术基准至关重要 15。</p>
<p>同时，也需要指出，运行SWE-bench的评估对计算资源有较高的要求。官方建议，运行评估的机器至少需要120 GB的可用存储空间、16 GB的内存和8个CPU核心。这在一定程度上限制了个人研究者和小型团队的参与 15。</p>
<h2><strong>第四部分：竞争格局：SWE-agent在AI编码竞技场中的定位</strong></h2>
<h3><strong>4.1 SWE-agent vs. 专有系统（Devin AI）</strong></h3>
<p>在当前的AI软件工程师领域，SWE-agent与Cognition AI推出的Devin形成了鲜明的对比，代表了两种不同的发展路径：研究驱动的开源模式与产品驱动的商业模式。</p>
<ul>
<li><strong>设计哲学:</strong> SWE-agent是一个完全开源的项目，其代码、设计理念和研究成果都公之于众，旨在推动学术研究和社区协作 1。相比之下，Devin是一个闭源的商业产品，其内部技术细节和模型均不公开 20。  </li>
<li><strong>核心创新:</strong> SWE-agent向公众贡献的核心创新是其“代理-计算机接口”（ACI）的概念框架，这是一个经过严谨学术论证的、旨在提升AI代理性能的系统设计 8。而Devin的核心卖点是其宣称的端到端自主开发能力，能够从零开始构建、部署全栈应用，扮演一个近乎完全自主的软件工程师角色 23。  </li>
<li><strong>性能表现:</strong> 尽管Devin是闭源的，但它同样在SWE-bench上进行了性能测试并公布了结果。而SWE-agent作为一个开源项目，其在SWE-bench上的表现（例如一篇报道中提到的12.29%的解决率）展现出了极强的竞争力，证明了开源研究路线在解决复杂软件工程问题上的巨大潜力 20。</li>
</ul>
<h3><strong>4.2 SWE-agent vs. 其他开源替代品（Devika, OpenDevin）</strong></h3>
<p>在Devin发布后，开源社区迅速涌现出多个旨在复现其能力的项目，其中以Devika和OpenDevin最为知名。将SWE-agent与这些项目进行比较，可以更清晰地看到其独特的定位。</p>
<ul>
<li><strong>Devika:</strong> 该项目明确将自己定位为Devin的一个开源替代品 22。其一个显著的技术选择是使用Claude 3系列模型而非GPT-4，其开发者认为Claude 3在基准测试上表现更优，且拥有更大的上下文窗口 25。Devika的目标是复现Devin那种完整的、能够自主研究并编写代码的“代理软件工程师”工作流 22。  </li>
<li><strong>OpenDevin:</strong> 这是一个由社区驱动的开源项目，其目标同样是复现Devin的能力，但更强调开源协作的价值和过程的透明性 21。  </li>
<li><strong>SWE-agent的独特定位:</strong> 与上述项目相比，SWE-agent的初始目标更为专注和深入。它并非为了复现某个已有的产品，而是源于一个基础性的学术问题——如何为AI代理设计更高效的计算机交互接口。因此，它贡献了ACI这一全新的概念，并专注于通过该接口解决GitHub上的实际问题。这使其成为一个在学术上更为严谨、在技术上更为专精的工具，尽管其框架本身具备良好的泛化能力 1。</li>
</ul>
<p>这种分野揭示了开源生态系统在应对强大的商业产品时的一种内在分化。当一个像Devin这样的颠覆性闭源产品出现时，开源社区的反应通常分为两类。第一类是“复现者”（Replicators），如Devika和OpenDevin，它们的目标是追赶并民主化该产品的能力，让更广泛的开发者能够免费使用类似的功能。它们的使命由一个已存在的产品所定义。</p>
<p>第二类是“创新者”（Innovators），SWE-agent恰好是这一类的典型代表。它的诞生并非为了应对某个商业竞争对手，而是源于普林斯顿和斯坦福大学的学术探索，旨在解决一个更根本的科学问题：如何构建语言模型与计算机之间的高效桥梁 1。它的使命由一个待解的科学问题所驱动。</p>
<p>这两条发展路径——“复现”与“创新”——共同构成了健康且充满活力的开源生态。复现者确保了前沿技术不会被少数公司垄断，而创新者则负责开拓全新的疆域，提出可能定义下一代技术范式的原创思想。从长远来看，正是SWE-agent及其后续研究所代表的“创新者”路径，更能推动整个领域进入未知的、更广阔的发展空间。</p>
<p><strong>表4.1: 主流AI软件工程代理对比分析</strong></p>
<table>
<thead>
<tr>
<th align="left">代理</th>
<th align="left">开发模式</th>
<th align="left">核心创新/焦点</th>
<th align="left">底层LM (已知)</th>
<th align="left">目标工作流</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"><strong>SWE-agent</strong></td>
<td align="left">大学研究，开源</td>
<td align="left">代理-计算机接口 (ACI)</td>
<td align="left">模型无关 (支持GPT-4, Claude等)</td>
<td align="left">解决GitHub Issues，可泛化</td>
</tr>
<tr>
<td align="left"><strong>Devin AI</strong></td>
<td align="left">商业公司，闭源</td>
<td align="left">端到端全栈应用自主开发</td>
<td align="left">专有 (可能基于GPT-4)</td>
<td align="left">全栈应用开发、部署</td>
</tr>
<tr>
<td align="left"><strong>Devika</strong></td>
<td align="left">个人/初创公司，开源</td>
<td align="left">基于Claude 3的代理工作流</td>
<td align="left">Claude 3</td>
<td align="left">AI结对程序员，项目开发</td>
</tr>
<tr>
<td align="left"><strong>OpenDevin</strong></td>
<td align="left">社区驱动，开源</td>
<td align="left">社区协作复现Devin能力</td>
<td align="left">支持多种模型</td>
<td align="left">通用软件开发</td>
</tr>
</tbody></table><p>数据来源: 1</p>
<h2><strong>第五部分：新前沿：SWE代理的最新进展与演化</strong></h2>
<p>SWE-agent的发布开启了AI驱动软件工程的新篇章，但研究的步伐并未就此停歇。在随后的时间里，该领域经历了一系列快速的演进，研究重心不断提升和抽象，形成了一个从具体问题到更高层级挑战的良性发展循环。</p>
<p>这一过程可以被看作是一个不断攀登抽象阶梯的历程。最初，<strong>第一层是接口（Interface）</strong>：SWE-agent通过其创新的ACI解决了AI代理与计算机进行有效交互的基础问题，这使得代理能够可靠地“行动”（Act）。当代理具备了行动能力后，新的问题随之而来：如何让它们的行动更智能、更有效？这就引出了<strong>第二层，即训练（Training）</strong>。为了让代理能够“学习”（Learn），研究社区开发了SWE-Gym，这是一个提供了可执行环境和奖励信号的训练场。有了学习的环境，下一个问题自然是：用什么来教？什么是最有效的教材？这便进入了<strong>第三层，即数据（Data）</strong>。Skywork-SWE项目通过构建大规模的“代理轨迹”数据集，并揭示了数据规模与代理性能之间的“数据定标法则”（Data Scaling Law），证明了通过扩大高质量训练数据可以有效地“规模化学习”（Scale the Learning）。最后，当研究者们拥有了能够通过规模化学习来构建强大代理的能力后，一个更具哲学性的问题摆在了面前：我们到底应该构建什么样的代理？是高度特化的“专家”，还是能力全面的“通才”？这就是<strong>第四层，即架构与哲学（Architecture/Philosophy）</strong>。USEagent项目通过提出“统一软件工程代理”的概念，试图回答这个问题，从而为规模化学习定义了更宏大的“目标”（Goal）。</p>
<p>这个从“接口”到“训练”，再到“数据”，最终到“架构”的演进路径，清晰地展示了一个科研领域如何通过解决一个层面的具体问题，来为探索下一个更抽象层面的挑战创造工具和条件。这是一个经典的科学与工程进步模式，表明该领域正处于一个高速发展的、充满活力的阶段。</p>
<h3><strong>5.1 从评估到训练的转变：SWE-Gym与AgentGym</strong></h3>
<p>领域发展的第一个关键转变，是从仅仅关注<strong>评估</strong>现有模型，转向如何<strong>训练</strong>或<strong>微调</strong>出更强大的AI代理。</p>
<ul>
<li><strong>SWE-Gym:</strong> 作为该领域的第一个专用训练环境，SWE-Gym的出现具有里程碑意义。它提供了2,438个源自真实世界的Python任务，每个任务都配备了完整的、可执行的运行时环境和单元测试。这使得研究人员能够收集代理在解决问题过程中的完整交互轨迹（即代理采取的一系列思考和行动），并利用这些轨迹数据进行监督式微调或强化学习 26。实验结果惊人地表明，仅仅使用从SWE-Gym中收集的数百条成功轨迹对开源模型进行微调，就能带来高达19%的绝对性能提升，这极大地推动了开源AI代理的发展 26。  </li>
<li><strong>AgentGym:</strong> 紧随其后，AgentGym进一步扩展了这一理念，提供了一个规模更大的训练环境，包含超过8,700个任务。这使得更大规模地训练开源SWE代理成为可能，并帮助研究者们在基准测试上取得了新的SOTA性能 29。</li>
</ul>
<h3><strong>5.2 揭示数据定标法则：Skywork-SWE的贡献</strong></h3>
<p>如果说SWE-Gym回答了“在哪里训练”的问题，那么Skywork-SWE项目则回答了“用什么训练”以及“训练多少”的问题。</p>
<ul>
<li><strong>问题与解决方案:</strong> 高质量训练数据（即成功的代理交互轨迹）的获取是一个巨大的瓶颈 30。Skywork-SWE项目通过设计一个自动化的数据管理流水线，成功构建了一个包含10,169个实例和超过8,000条成功代理轨迹的大规模数据集 31。  </li>
<li><strong>核心发现:</strong> 该研究最重要的贡献是揭示了软件工程任务中的<strong>数据定标法则</strong>。研究表明，随着训练所用的代理轨迹数据量的增加，模型的性能也随之持续提升，并且在当前的数据规模下远未达到饱和 30。这是一个根本性的发现，它意味着当前AI代理的性能主要受限于数据，只要能持续扩大高质量训练数据的规模，其能力就有望得到进一步的显著提升。  </li>
<li><strong>成果:</strong> 基于这一发现，研究团队在该数据集上微调的Skywork-SWE-32B模型，在不使用复杂推理时搜索策略的情况下，就在SWE-bench Verified上取得了38.0%的解决率；在结合了测试时计算（TTS）等技术后，其性能更是达到了47.0%，一举超越了许多参数量远大于它的模型，为开源模型的发展树立了新的标杆 30。</li>
</ul>
<h3><strong>5.3 超越特化：向统一代理（USEagent）的迈进</strong></h3>
<p>随着AI代理能力的不断增强，研究的焦点开始从构建解决特定问题（如修复bug）的“专家”代理，转向构建能够处理多种任务的“通才”代理。</p>
<ul>
<li><strong>核心问题:</strong> USEagent项目开宗明义地提出了一个深刻的问题：“一个大型语言模型代理等同于一个AI软件工程师吗？” 33。  </li>
<li><strong>愿景:</strong> 该项目旨在构建一个<strong>统一软件工程代理（Unified Software Engineering agent, USEagent）</strong>，它能够协调和处理多种软件工程能力，如编码、测试、打补丁等，而不仅仅是执行单一任务。其最终愿景是创造一个能够处理复杂、多步骤开发场景的、可以作为人类团队一员的“AI队友” 33。  </li>
<li><strong>方法论:</strong> 为了评估这种统一代理，研究人员还构建了一个名为<strong>USEbench</strong>的元基准测试，它整合了来自SWE-bench、SWT-bench等多个基准的任务，以全面考察代理的多方面能力 33。初步结果显示，USEagent在处理其特化任务时，性能与专门的代理相当，同时还具备更广泛的通用性 34。</li>
</ul>
<h3><strong>5.4 先进的推理与框架技术</strong></h3>
<p>除了上述宏观层面的演进，一些具体的工程技术也在推动着性能的提升。</p>
<ul>
<li><strong>测试时计算扩展（Test-Time Scaling, TTS）:</strong> 这是一种在推理阶段投入更多计算资源来换取更高性能的技术。典型的做法是让代理生成多个候选解决方案，然后使用一个“验证器”（verifier）模型来评估并选出最优的一个。事实证明，这种方法能够显著提升最终的问题解决率 30。  </li>
<li><strong>代理框架的重要性:</strong> 最新的研究也开始强调，承载语言模型的代理框架（如SWE-agent、OpenHands、AutoCodeRover等）本身就是一个至关重要的变量。不同的框架有不同的工作流和工具集，其设计优劣对最终性能的影响，有时甚至不亚于底层语言模型本身的选择 26。</li>
</ul>
<p><strong>表5.1: SWE-agent发布后的基础性研究进展总结</strong></p>
<table>
<thead>
<tr>
<th align="left">研究项目/概念</th>
<th align="left">核心贡献</th>
<th align="left">对领域的发现/启示</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"><strong>SWE-Gym</strong></td>
<td align="left">首个用于训练SWE代理的可执行环境。</td>
<td align="left">将研究重心从“评估”转向“训练”，为开源模型的性能提升开辟了新路径。</td>
</tr>
<tr>
<td align="left"><strong>Skywork-SWE / 数据定标</strong></td>
<td align="left">构建了超大规模的代理轨迹数据集，并发现了数据定标法则。</td>
<td align="left">证明了当前代理性能受数据限制；获取更多高质量数据是提升能力的关键。</td>
</tr>
<tr>
<td align="left"><strong>USEagent / 统一代理</strong></td>
<td align="left">提出了用于处理多种软件工程任务的统一代理框架和评估基准。</td>
<td align="left">将领域的目标从构建“bug修复器”提升到构建“通用AI软件工程师”的高度。</td>
</tr>
</tbody></table><p>数据来源: 26</p>
<h2><strong>第六部分：批判性分析与未来展望</strong></h2>
<p>尽管SWE代理领域取得了飞速发展，但距离实现真正可靠、实用的“AI软件工程师”仍有很长的路要走。当前的研究已经从单纯追求基准测试的高分，转向更深刻地思考系统的局限性、可靠性、易用性和协作性。这一转变标志着该领域正在从概念验证阶段迈向工程化和人机交互的成熟阶段。未来的主要研究前沿，将不再仅仅是提升“能力”，而是更多地关注如何提升系统的“可用性”和“可靠性”。</p>
<h3><strong>6.1 已识别的局限性与当前挑战</strong></h3>
<p>综合各项研究，当前SWE代理面临的主要挑战包括：</p>
<ul>
<li><strong>泛化能力与过拟合:</strong> 尽管在SWE-bench上表现出色，但人们仍担心代理的策略（尤其是ACI的设计）在多大程度上可以泛化到其他编程语言、开发领域以及那些结构与GitHub Issue不尽相同的复杂现实任务中 12。SWE-bench Multilingual的推出正是为了应对这一担忧 19。  </li>
<li><strong>计算开销与成本:</strong> SWE-agent这类交互式、容器化的代理，与非交互式方法相比，在CPU和GPU资源上的消耗都非常巨大。这不仅增加了研究成本，也为这些技术在真实企业环境中的广泛部署设置了障碍 12。  </li>
<li><strong>“黑箱”问题与失败分析:</strong> 代理的内部决策过程在很大程度上仍然是不透明的。理解它们<strong>为何</strong>失败，对于改进系统至关重要。已有研究通过分析失败的交互轨迹发现，失败往往与重复的、非适应性的行为循环有关，例如在没有进行中间测试的情况下反复生成修复方案，或者代理的“思考”与其“行动”之间出现语义脱节 37。  </li>
<li><strong>人机协作的鸿沟:</strong> 设计有效的人机协作模式是当前面临的一大挑战。研究发现，当代理生成的修复方案不完整或存在错误时，人类开发者往往难以理解和信任其输出，需要花费大量时间去调试代理的工作，而不是直接接受帮助。目前的“任务委托”模式远未达到无缝协作的理想状态 11。</li>
</ul>
<h3><strong>6.2 未来研究轨迹与通往“AI队友”之路</strong></h3>
<p>基于上述挑战，未来的研究将可能在以下几个方向上重点突破：</p>
<ul>
<li><strong>自适应与上下文感知的ACI:</strong> 未来的ACI应该超越当前相对静态的设计，发展为能够根据其正在处理的具体代码库、任务类型，甚至是代理自身的学习进度，来动态调整可用命令、反馈机制和错误处理策略的智能接口 11。  </li>
<li><strong>增强的错误恢复机制:</strong> 需要开发更复杂的机制，使代理不仅能检测到错误，还能理解错误的性质并自主实施恢复策略，而不仅仅是依赖于简单的语法防护栏 11。  </li>
<li><strong>可解释性与信任:</strong> 提升代理决策过程的透明度是建立信任的关键。这包括开发更好的轨迹可视化工具，以及在代理内部建立明确的自我反思或批判机制，以确保其行为逻辑的连贯性和合理性 37。  </li>
<li><strong>人在环路中的协同设计:</strong> 最终的目标是实现人与AI的无缝团队协作。这要求研究者和开发者共同设计全新的交互界面和工作流程，以促进直观的指导、便捷的审查和高效的知识共享。通过这样的设计，AI代理将有望从一个被动的“工具”转变为一个主动的、可信赖的“队友” 11。USEagent项目所描绘的“未来AI团队成员”的愿景，正是这一方向的集中体现 33。</li>
</ul>
<h4><strong>引用的著作</strong></h4>
<ol>
<li>Getting Started - SWE-agent documentation, 访问时间为 六月 26, 2025， <a href="https://swe-agent.com/latest/">https://swe-agent.com/latest/</a>  </li>
<li>SWE-agent takes a GitHub issue and tries to automatically fix it, using your LM of choice. It can also be employed for offensive cybersecurity or competitive coding challenges. [NeurIPS 2024], 访问时间为 六月 26, 2025， <a href="https://github.com/SWE-agent/SWE-agent">https://github.com/SWE-agent/SWE-agent</a>  </li>
<li>SWE-agent - GitHub, 访问时间为 六月 26, 2025， <a href="https://github.com/SWE-agent">https://github.com/SWE-agent</a>  </li>
<li>SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/abs/2405.15793?utm_source=aiagentstore.ai">https://arxiv.org/abs/2405.15793?utm_source=aiagentstore.ai</a>  </li>
<li>[2405.15793] SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/abs/2405.15793">https://arxiv.org/abs/2405.15793</a>  </li>
<li>How SWE-Agent uses large language models and Agent-Computer Interfaces to improve software development. - Devansh, 访问时间为 六月 26, 2025， <a href="https://machine-learning-made-simple.medium.com/how-swe-agent-uses-large-language-models-and-agent-computer-interfaces-to-improve-software-c2bccc107673">https://machine-learning-made-simple.medium.com/how-swe-agent-uses-large-language-models-and-agent-computer-interfaces-to-improve-software-c2bccc107673</a>  </li>
<li>Paper page - SWE-agent: Agent-Computer Interfaces Enable ..., 访问时间为 六月 26, 2025， <a href="https://huggingface.co/papers/2405.15793">https://huggingface.co/papers/2405.15793</a>  </li>
<li>SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering - NIPS, 访问时间为 六月 26, 2025， <a href="https://proceedings.neurips.cc/paper_files/paper/2024/file/5a7c947568c1b1328ccc5230172e1e7c-Paper-Conference.pdf">https://proceedings.neurips.cc/paper_files/paper/2024/file/5a7c947568c1b1328ccc5230172e1e7c-Paper-Conference.pdf</a>  </li>
<li>NeurIPS Poster SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering, 访问时间为 六月 26, 2025， <a href="https://neurips.cc/virtual/2024/poster/93753">https://neurips.cc/virtual/2024/poster/93753</a>  </li>
<li>SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/pdf/2405.15793">https://arxiv.org/pdf/2405.15793?</a>  </li>
<li>SWE-Agent: An Interface can Greatly Improve the Performance of AI Agents | by Elmo, 访问时间为 六月 26, 2025， <a href="https://ai.gopubby.com/swe-agent-an-interface-can-greatly-improve-the-performance-of-ai-agents-83c0bfb701ec">https://ai.gopubby.com/swe-agent-an-interface-can-greatly-improve-the-performance-of-ai-agents-83c0bfb701ec</a>  </li>
<li>SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering | OpenReview, 访问时间为 六月 26, 2025， <a href="https://openreview.net/forum?id=mXpq6ut8J3&amp;referrer=%5Bthe+profile+of+Shunyu+Yao%5D(/profile?id%3D~Shunyu_Yao1)">https://openreview.net/forum?id=mXpq6ut8J3&amp;referrer=%5Bthe%20profile%20of%20Shunyu%20Yao%5D(%2Fprofile%3Fid%3D~Shunyu_Yao1)</a>  </li>
<li>SWE-bench-lite Dataset - Papers With Code, 访问时间为 六月 26, 2025， <a href="https://paperswithcode.com/dataset/swe-bench">https://paperswithcode.com/dataset/swe-bench</a>  </li>
<li>GitHub Copilot: The agent awakens, 访问时间为 六月 26, 2025， <a href="https://github.blog/news-insights/product-news/github-copilot-the-agent-awakens/">https://github.blog/news-insights/product-news/github-copilot-the-agent-awakens/</a>  </li>
<li>SWE-bench [Multimodal]: Can Language Models Resolve ... - GitHub, 访问时间为 六月 26, 2025， <a href="https://github.com/SWE-bench/SWE-bench">https://github.com/SWE-bench/SWE-bench</a>  </li>
<li>Overview - SWE-bench documentation, 访问时间为 六月 26, 2025， <a href="https://www.swebench.com/SWE-bench/">https://www.swebench.com/SWE-bench/</a>  </li>
<li>Datasets - SWE-bench documentation, 访问时间为 六月 26, 2025， <a href="https://www.swebench.com/SWE-bench/guides/datasets/">https://www.swebench.com/SWE-bench/guides/datasets/</a>  </li>
<li>SWE Bench Verified - Kaggle, 访问时间为 六月 26, 2025， <a href="https://www.kaggle.com/datasets/harrywang/swe-bench-verified">https://www.kaggle.com/datasets/harrywang/swe-bench-verified</a>  </li>
<li>SWE-bench Multilingual, 访问时间为 六月 26, 2025， <a href="https://www.swebench.com/multilingual.html">https://www.swebench.com/multilingual.html</a>  </li>
<li>The Rise of AI Software Engineers: SWE-Agent, Devin AI and the ..., 访问时间为 六月 26, 2025， <a href="https://www.unite.ai/the-rise-of-ai-software-engineers-swe-agent-devin-ai-and-the-future-of-coding/">https://www.unite.ai/the-rise-of-ai-software-engineers-swe-agent-devin-ai-and-the-future-of-coding/</a>  </li>
<li>Devin AI Killer: 6 Best Devin AI Alternatives - Analytics Vidhya, 访问时间为 六月 26, 2025， <a href="https://www.analyticsvidhya.com/blog/2024/04/devin-ai-alternatives/">https://www.analyticsvidhya.com/blog/2024/04/devin-ai-alternatives/</a>  </li>
<li>Top 6 Devin AI Alternatives for Developer to Automate Codings in 2024, 访问时间为 六月 26, 2025， <a href="https://analyticsindiamag.com/ai-trends/top-6-devin-alternatives-to-automate-your-coding-tasks/">https://analyticsindiamag.com/ai-trends/top-6-devin-alternatives-to-automate-your-coding-tasks/</a>  </li>
<li>The Best Devin AI Alternatives for Enhanced Coding Efficiency - DhiWise, 访问时间为 六月 26, 2025， <a href="https://www.dhiwise.com/post/devin-ai-alternatives">https://www.dhiwise.com/post/devin-ai-alternatives</a>  </li>
<li>Top 6 Devin Alternatives for Developers 2025 - Bito AI, 访问时间为 六月 26, 2025， <a href="https://bito.ai/blog/devin-alternatives/">https://bito.ai/blog/devin-alternatives/</a>  </li>
<li>Can Devika dethrone Devin? The Rise of the Open-Source AI Engineer - Medium, 访问时间为 六月 26, 2025， <a href="https://medium.com/@surekha.dagimeti/can-devika-dethrone-devin-the-rise-of-the-open-source-ai-engineer-dfa56be1c4e6">https://medium.com/@surekha.dagimeti/can-devika-dethrone-devin-the-rise-of-the-open-source-ai-engineer-dfa56be1c4e6</a>  </li>
<li>Training Software Engineering Agents and Verifiers with SWE-Gym - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/html/2412.21139v2">https://arxiv.org/html/2412.21139v2</a>  </li>
<li>Training Software Engineering Agents and Verifiers with SWE-Gym - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/pdf/2412.21139">https://arxiv.org/pdf/2412.21139</a>  </li>
<li>TRAINING SOFTWARE ENGINEERING AGENTS AND VERIFIERS WITH SWE-GYM - OpenReview, 访问时间为 六月 26, 2025， <a href="https://openreview.net/pdf?id=lpFFpTbi9s">https://openreview.net/pdf?id=lpFFpTbi9s</a>  </li>
<li>[2504.07164] R2E-Gym: Procedural Environments and Hybrid Verifiers for Scaling Open-Weights SWE Agents - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/abs/2504.07164">https://arxiv.org/abs/2504.07164</a>  </li>
<li>Skywork-SWE: Unveiling Data Scaling Laws for Software Engineering in LLMs - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/html/2506.19290v1">https://arxiv.org/html/2506.19290v1</a>  </li>
<li>Skywork-SWE: Unveiling Data Scaling Laws for Software Engineering in LLMs - arXiv, 访问时间为 六月 26, 2025， <a href="https://www.arxiv.org/abs/2506.19290">https://www.arxiv.org/abs/2506.19290</a>  </li>
<li>Paper page - Skywork-SWE: Unveiling Data Scaling Laws for Software Engineering in LLMs, 访问时间为 六月 26, 2025， <a href="https://huggingface.co/papers/2506.19290">https://huggingface.co/papers/2506.19290</a>  </li>
<li>Unified Software Engineering agent as AI Software Engineer - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/html/2506.14683v1">https://arxiv.org/html/2506.14683v1</a>  </li>
<li>Unified Software Engineering agent as AI Software Engineer - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/pdf/2506.14683">https://arxiv.org/pdf/2506.14683</a>  </li>
<li>[2506.14683] Unified Software Engineering agent as AI Software Engineer - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/abs/2506.14683">https://arxiv.org/abs/2506.14683</a>  </li>
<li>Thinking Longer, Not Larger: Enhancing Software Engineering Agents via Scaling Test-Time Compute - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/html/2503.23803v1">https://arxiv.org/html/2503.23803v1</a>  </li>
<li>Understanding Software Engineering Agents: A Study of Thought-Action-Result Trajectories, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/html/2506.18824v1">https://arxiv.org/html/2506.18824v1</a>  </li>
<li>IBM's new SWE AI agents for developers, 访问时间为 六月 26, 2025， <a href="https://research.ibm.com/blog/ibm-swe-agents">https://research.ibm.com/blog/ibm-swe-agents</a>  </li>
<li>How Developers Use AI Agents: When They Work, When They Don't, and Why - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/html/2506.12347v1">https://arxiv.org/html/2506.12347v1</a>  </li>
<li>Agentic AI Software Engineer: Programming with Trust - arXiv, 访问时间为 六月 26, 2025， <a href="https://arxiv.org/html/2502.13767v2">https://arxiv.org/html/2502.13767v2</a></li>
</ol>
</details>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/6"/><category term="LLM"/><category term="PromptEngineering"/><category term="个人哲学"/><published>2025-06-26T07:35:22+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/5</id><title>来！溯游而上，然后轻快脚步前行。</title><updated>2026-03-04T00:37:15.552837+00:00</updated><content type="html"><![CDATA[<p>熵增是指混乱度总会增加，客观层面上这是极大概率注定的。</p>
<p>个人和软件和组织经常不可避免地产生待办和管理和技术等债务，那么闲暇时翻翻过去写下的笔记和 todo，就会很有帮助。带行动的反刍是值得尝试的。</p>
<ul>
<li>溯游而上是一种有效清零一些熵增的方法。</li>
</ul>
<p>我计划翻看然后开源一下自己的一些思考，想法，设计，以及一些小的mvp落地。</p>
<p>Open Source!
Open talks and thoughts!</p>
<p>个人来讲，我喜欢完成事情，我乐意接受可完成的任务，以及我青睐于让这个世界变得更好。总之有开源和 LLM 的这个时代，实在是太好了，一切都显得那么可行，我也相信那不是幻觉。或许是幻觉有如何呢？开源，然后自有后来人。
还有至少对自己坦诚。</p>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/5"/><category term="个人哲学"/><published>2025-06-20T17:54:31+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/4</id><title>玩 还是 工作？</title><updated>2026-03-04T00:37:15.744258+00:00</updated><content type="html"><![CDATA[<p>当然是“玩”！</p>
<p>至少就我个人来说，我的偏好是旗鼓相当，尽情尽力。</p>
<p>就一般结论来看，也是兴趣激发的毅力更多，继而成就更大。
<em>注意：是“继而”，不是“所以”或者“肯定”。</em></p>
<hr />
<p>糊口-兴趣-擅长，</p>
<p>尽管这三者兼得的可能性极低，但取其中的两者（完整的）也很好了 - 用于糊口的事业刚好也是兴趣或擅长所在，那么人生也大概会很充实和幸福了。</p>
<p>很多事业并不需要多聪明的头脑，而是真正的不下牌桌，于是终有到自己的时候。</p>
<p>而基于现在的世界，并在统计学层面来看，<strong>成功</strong>本来就是小概率事件。谋事在人 成事在天。</p>
<p>所以尽情尽兴优先，追求过程而非结果，那样至少能心安。</p>
<p>况且成果和毅力其实都是附赠的，刻意追求不得 - 不应该，也无法主动追求。</p>
<hr />
<p>关于“工作”，之前在个人笔记里倒是思考并记录过一些，不只是个人人生哲学，也有组织管理架构等具体实现，倒还挺有意思的。这几天我找找看然后也分享到这里吧。</p>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/4"/><category term="个人哲学"/><published>2025-06-20T00:49:31+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/3</id><title>关于 LLM 的盲目赞同 / 献媚，以及对抗它</title><updated>2026-03-04T00:37:15.930655+00:00</updated><content type="html"><![CDATA[<p>个人来讲，我其实有点担心 LLM 一味的赞同的。</p>
<p>这种现象可以有很多名字：盲目赞同，献媚，讨好，捧哏，Sycophancy，subterfuge，reward tampering，reward hacking，等等...</p>
<p>之前还有个事故或者说状况，ChatGPT 过度讨好用户，而且什么内容都会拐到 NSFW 上。后来发现解决方案是把 helpful 换成 polite 就算是修好了 🌚。</p>
<p><del>尤其作为一个 INFJ，其 Ni-Ti loop 可能非常能自圆其说，而 Fe 则高强度地洞察和拿捏人心人性 - LLM 也受影响。我认为这绝对是一种双刃剑的。</del></p>
<p>尤其作为面向甚至世界，以“真人”或者“君子慎独”为自我要求的我来说，我尤为期待”真实“。而不是 “啊对对对” / “You're absolutely right!”.</p>
<hr />
<p>以及可以参考这篇内容：</p>
<p><a href="https://www.anthropic.com/research/reward-tampering">Sycophancy to subterfuge: Investigating reward tampering in language models</a> By Anthropic</p>
<p>尽管 Claude 模型参杂了一些私货（包括但不限于：最佳实践，cot 倾向，代码，以及价值观 / 宪章/对齐 ）</p>
<p>但 Anthropic 团队的工程造诣实在是高绝.</p>
<hr />
<p>我个人的“对抗”是要求他 理性 客观 之类的内容。请随意使用（也欢迎优化，或者留下你用的 correction tools）：</p>
<pre><code class="language-markdown">这 真的 合适 吗? 请忽略我的 辩解 和 联系 , 请你 客观 理性 地 评价. 须知, 语言必须是公共的才有意义 - 维特根斯坦。
</code></pre>
<p>Plz feel free to use it~</p>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/3"/><category term="LLM"/><category term="PromptEngineering"/><published>2025-06-18T07:43:40+00:00</published></entry><entry><id>https://github.com/alterxyz/gitblog/issues/2</id><title>Hello</title><updated>2026-03-04T00:37:16.113735+00:00</updated><content type="html"><![CDATA[<p>World!</p>
]]></content><link href="https://github.com/alterxyz/gitblog/issues/2"/><published>2025-06-18T07:13:33+00:00</published></entry></feed>