那时难决

我近期开发了一款Rust命令行工具Everyday CLI，
配合自带的Skill，
可为 AI Agent 提供便捷的邮箱、日历、RSS 订阅、笔记、待办事项及书签管理能力。。
我几乎全程在腾讯推出的 WorkBuddy 上进行开发，期间不断切换模型与工作流，推动项目逐步迭代至较完善版本，也积累了不少实践经验。

WorkBuddy 除腾讯混元模型外，还集成了多款国产开源模型，其中包括业界公认的领先模型 GLM-5.2。
Everyday CLI项目的基础搭建和前期开发使用的就是GLM 5.2模型，总体质量令人满意。
然而 GLM-5.2 调用成本较高，迅速消耗了我大部分的积分余额。此前我因参与 WorkBuddy 早期营销活动累计获赠七千余积分，仅不到两天就由 GLM-5.2 耗去了三四千。
这一消耗速度相当惊人——WorkBuddy 每月 70 元的基础订阅仅赠送 4000 积分，重度使用下往往一两天便告罄。

积分告急后，我转而使用腾讯自研的 HY3 模型（近期刚由 HY3-Preview 升级为正式版，目前在 WorkBuddy 及 OpenRouter 平台限时免费）。
HY3的总体参数量和GLM 5.2还是有一定的差距，不过在成熟的 Harness 框架支撑下，项目推进依然顺畅。
此外，我还另行订阅了 MiniMax Token Plan，并在 WorkBuddy 中手动接入了 MiniMax M3 模型。
体验时发现M3模型有些过度思考的倾向，在很多场景下可能还不如HY3模型的体验好。
针对这一问题，我手动安装并启用了 Caveman
Skill，强制压缩输出风格，取得了显著的优化效果。

我认为 Rust 在 Code Agent 场景下具备独特优势：其质量门禁（rust fmt与 Clippy）及编译器反馈均十分明确，能有效弥补模型能力的波动。

此前使用 GitHub Copilot 时，我习惯于先通过 /plan规划模式制定方案，确认后再着手开发。
鉴于 WorkBuddy 未内置规划模式，我改为使用planning-with-files skill，
依托 task_plan.md、progress.md与 findings.md三类文档，分别追踪项目计划、实施进度及关键决策与技术要点。

本周末我接触到了grill-with-docs Skill，
该技能会在方案制定前深入质询各项关键设计决策，并将其固化为 ADR（架构决策记录，过程中虽消耗较多 Token），最终助力我顺利完成了 Timeline 模块的开发。

Everyday CLI 目前仍在高频迭代中，欢迎各位关注、试用并提出宝贵意见与建议。

参考链接：

• Everyday CLI项目: https://github.com/duyixian1234/everyday
• WorkBuddy: https://www.codebuddy.cn/work/
• GLM 5.2: https://z.ai/blog/glm-5.2
• HY3: https://hy.tencent.com/research/hy3
• Minimax M3: https://www.minimaxi.com/blog/minimax-m3
• Caveman Skill: https://www.skills.sh/juliusbrussee/caveman/caveman
• Planning-with-files Skill: https://www.skills.sh/othmanadi/planning-with-files/planning-with-files
• Grill-with-docs Skill: https://www.skills.sh/mattpocock/skills/grill-with-docs

微软近期正式发布了WSL container CLI(wslc.exe)，可以直接在windows上管理Linux 容器，不必再安装Docker Destop或在某个wsl实例里安装docker ce。

wslc.exe随最新的wsl预览版发布，可通过wsl --update --pre-release命令升级。

wslc.exe的命令行语法与docker高度一致，开发者（以及AI Agent）可以使用熟悉的命令。

近期微信推出了官方的 Clawbot 插件和官方的 Openclaw Plugin，用于配置 Openclaw 连接。与此同时，其他 Openclaw 类工具也纷纷接入了微信 Clawbot。

我使用的 Zeroclaw 暂时还没有官方的微信 Clawbot 接入方案，不过可以通过 OpeniLink Hub 来间接实现 Zeroclaw 与微信 Clawbot 的连接。

OpeniLink Hub 是一个基于微信官方 iLink 协议的开源微信机器人（Bot）管理平台，同时也是一个 App 应用市场。

它主要提供以下能力：

• 支持多账号扫码绑定
• 提供内置应用市场，可一键扩展飞书、Slack、Notion 等 20 多种工具
• 支持 AI 自动回复能力

我将自己的微信 Clawbot 连接到了 OpeniLink Hub，并安装了两个内置应用：

1. MCP Server

   • 提供向微信发消息的能力
   • 配置到 Zeroclaw 中后，可以让 Zeroclaw 向微信发送消息

2. Runner

   • 提供斜杠命令能力
   • 可以在微信中通过 /agent 触发 Zeroclaw 中的功能

虽然微信的 Clawbot 对于 Markdown 消息、流式消息等功能的支持还不完善，但通过 OpeniLink Hub 的中转，Zeroclaw 的功能可以在微信中得到一定程度的展现,目前可以满足一些简单的消息交互需求。

在技术领域，2026年的第一季度属于OpenClaw，近期我也开始了自己的“养龙虾”之旅。
我个人非常不愿意在个人设备上给予AI过多的权限（比如屏幕读取和文件系统权限），所以选择了在一台云服务器安装“龙虾”。作为一个TypeScript实现的node.js服务，原版的OpenClaw需要消耗相当高的服务器资源（运行时占用1GB以上的内存）。考虑到我的云服务器只有4GB内存，我最终选择安装配置了zeroclaw（一个rust实现的轻量级OpenClaw同类产品）。

运行ZeroClaw服务仅需一个约15MB大小的二进制文件，安装配置流程极为简便，运行时只需要不到10MB的内存，并且可以通过zeroclaw service install命令自动配置systemd服务。

ZeroClaw支持多种AI服务提供商，我使用的火山引擎的方舟Coding Plan（支持豆包模型以及Deepseek、GLM、Minimax等国产主流模型）。经过我的一番测试，我发现Doubao 2.0 Pro模型的表现比GLM 4.7和Minimax M2.5好一点。

OpenClaw类产品比起Claude Codede的一个显著优势就是可以通过即时通信软件直接和AI进行交互，支持用户随时随地通过个人设备调用AI执行自动化任务。

我给自己的ZeroClaw服务配置了QQ机器人的接入，值得注意的是我的ZeroClaw服务是通过Cloudflare Tunnel暴露到公网上的，域名没有进行备案，所以只能通过WebSocket方式接入QQ机器人，不能通过配置Webhook的方式接入（腾讯最近推出的 Workbuddy 和 QClaw 服务接入 QQ 机器人，提供了官方 Webhook 链接用于配置。）。

由于没有运行在个人设备上，无法管理个人文档和数据，我主要利用ZeroClaw进行一些定时的自动化信息获取任务。我配置了一个每天早上的“晨间播报”定时任务，推送当天的天气情况，待办事项和日程安排等信息。

我还配置了一个每天获取当天的AI资讯的定时任务，并且迭代了很多次。

一开始是直接通过ZeroClaw自己的搜索工具获取AI相关资讯，但发现获取到的资讯质量很不可控。
后来编写了一个Python脚本，直接从RSS源获取相关资讯，让ZeroClaw定时执行这个脚本，测试时发现 AI 竟然在无监督的情况下‘自作主张’修改了脚本中的 RSS 源列表，替换成了36氪和其他部分国内媒体的RSS源，这些媒体有相当一部分的报道是带有商业推广倾向的（即通常所说的“软文”），质量参差不齐。

我从这个案例学到一个深刻的教训，和使用Github Copilot或Claude Code等工具进行开发工作不同，在具备写权限和执行权限的环境中不能随意让AI在无监督的情况下运行AI自生成的代码（或者修改现有代码）。

最终我选择了使用crontab定时运行Python脚本获取RSS源的更新，将内容写到文本文件中，在定时任务中让ZeroClaw直接读取文本文件中的信息，精选出当天高价值的资讯推送给我。

总的来说，ZeroClaw 是一个非常有潜力的个人 AI 基础设施。这次‘养龙虾’之旅不仅帮我建立了一个趁手的自动化助手，也让我对 Agent 时代的权限隔离和确定性工程有了更直观的体悟。未来我会继续探索和利用这个工具来提升我的工作效率和生活品质。

在现有架构下，我主要维护的是一个运行在 AlmaLinux ECS 实例上的后端服务：基于 FastAPI 构建，通过 Docker Compose 进行容器化部署。服务中包含多条 AI 对话类 SSE（Server-Sent Events）长连接接口。

随着用户规模增加，我逐渐发现一个现实问题：Docker Compose 在滚动发布和长连接共存场景下，几乎无法实现真正的零停机更新。容器重建过程中，SSE 连接被强制断开，用户体验受到明显影响。

在与 AI 进行多轮技术探讨后，我重新审视了技术选型。结论是：在当前规模与复杂度下，并不需要直接迁移到 Kubernetes。采用 Docker Swarm 即可满足零停机更新与滚动发布的需求，同时保持架构复杂度可控。

经过半天实践，我成功将服务从 Docker Compose 迁移至 Docker Swarm。以下是关键迁移步骤与问题记录。

一、初始化 Swarm 集群

在 ECS 主机上执行：

docker swarm init

该命令会将当前 Docker Engine 切换为 Swarm 模式，并初始化为单节点集群（Manager）。对于单机部署场景，这已经足够。

二、调整 Compose 文件结构

Swarm 兼容 Compose 文件格式，但需要引入 deploy 段定义编排策略，例如：

• replicas：副本数量
• update_config：更新策略（并行数、延迟、顺序等）
• restart_policy：重启策略

例如可配置：

• 每次只更新一个副本
• 新副本就绪后再停止旧副本（start-first 策略）

这一步是实现“零停机滚动更新”的核心。

三、使用 Stack 部署

Swarm 不再使用 docker-compose up，而是通过 Stack 进行编排部署：

docker stack deploy -c docker-compose.yml your_stack_name

Stack 会将服务转换为 Swarm Service，并交由调度器管理。

四、迁移过程中遇到的问题

1. 本地构建镜像无法拉取

由于镜像是本地构建，未推送至 Docker Hub 或私有仓库，Swarm 默认会尝试从远程仓库解析镜像并拉取，导致部署失败。

解决方式是在部署时添加：

–resolve-image never

该参数指示 Swarm 跳过远程镜像解析，直接使用本地镜像。

2. Swarm 网络无法直接访问宿主机服务

在 Compose 模式下，容器可以通过 bridge 网络访问宿主机服务（如本地数据库或 Redis）。但在 Swarm overlay 网络中，默认无法直接访问宿主机 127.0.0.1。

解决方案是将服务地址改为：

host.docker.internal

或在 Linux 环境中使用：

host-gateway

并在 compose 文件中通过 extra_hosts 显式声明 host-gateway 映射。这样容器即可访问宿主机网络资源。

五、迁移结果与技术判断

迁移至 Docker Swarm 后：

• 支持多副本运行
• 支持滚动更新与回滚
• SSE 长连接在发布期间不中断
• 架构复杂度远低于 Kubernetes

在当前业务规模下，Swarm 提供了一个性价比极高的“轻量级编排层”。它弥补了 Docker Compose 在生产环境部署能力上的不足，同时避免了 Kubernetes 带来的学习成本和运维复杂度。

对于单机或小规模集群的 AI 服务而言，这是一个务实且工程上合理的选择。

在近期的 AI 辅助开发实践中，我逐步形成了一套相对稳定、可复用的工作流，核心目标是：让 AI 可规划、可执行、可追踪、可审查。

整体流程如下：

首先，为每个项目建立专属的 agents.md，用于描述项目背景、技术约束以及 AI 开发规范，例如强制要求在代码生成后执行静态检查和单元测试。这一步相当于为 AI 提供“项目宪法”。

其次，提出足够明确、结构化的需求，并使用 Copilot 的 Planning 模式生成开发计划，避免直接进入无序实现。

在实施阶段，切换至 Copilot 的 Agent 模式执行计划，并明确要求使用 PRD.md 和 process.md 跟踪进度：前者记录需求，后者记录每次代码变更与当前状态。通过外部文件系统作为长期记忆，降低上下文丢失的风险。

完成初步实现后，由人工对功能正确性进行验证，确保需求被真实满足，而非“看起来能跑”。

最后，引入我自定义的Linus 风格 Code Review Agent进行代码审查，集中指出设计、可维护性和工程质量问题，再由人工或 AI 执行针对性的重构。

值得一提的是，近期社区中出现了一个名为 planning-with-files 的 Claude Skill，其思路与上述流程高度相似，同样通过外部文件作为 AI 的长期记忆，并额外引入 findings.md 用于沉淀调研结论和经验知识。这类模式进一步验证了“文件即上下文”的工程价值。

1
2

# Skill安装命令
npx skills add https://github.com/othmanadi/planning-with-files --skill planning-with-files

总体来看，AI 开发正在从“对话式生成”走向“工程化协作”，而可追踪的计划、状态与知识载体，是这一转变的关键基础。

Zed 是一款由前 Atom 及 Tree-sitter 团队打造的跨平台代码编辑器。它采用 Rust 语言编写，核心定位在于极致性能、原生 AI 集成以及多人实时协作。

Zed is a minimal code editor crafted for speed and collaboration with humans and AI.

得益于 Rust 语言的底层优势和自研的 GPU 加速框架 GPUI，Zed 在响应速度上远超基于 Electron 的编辑器。
在处理中等规模项目时，Zed 的内存占用通常仅为 VS Code 的十分之一左右（约 100MB vs 1GB+）。
Zed 充分利用多核 CPU 和 GPU 渲染，使得输入延迟和 UI 刷新达到了原生应用的最佳水准。

Zed集成了很多AI开发功能，包括代码智能补全、编辑预测、Agent开发模式。
除了登录账号订阅Zed官方的AI服务外，用户还可以通过BYOK模式使用自己的OpenAI、Gemini或Claude API密钥（也可以直接使用Github Copilot订阅）。
Zed也支持和Claude Code、Gemini CLI与Codex CLI集成。

虽然插件生态尚处于早期阶段，但 Zed 通过原生支持 LSP（语言服务协议），已实现对 Python、Rust、TypeScript 等主流语言的完美支持。

对于追求极致流畅度、且希望在开发流中深度使用 AI 的开发者来说，Zed 无疑是目前 VS Code 最强有力的挑战者。

【由 ChatGPT 辅助翻译】

原文链接

发布时间: 2025-12-26

uv 安装包的速度比 pip 快一个数量级。通常的解释是“它是用 Rust 写的”。这确实没错，但并不能解释太多。毕竟，也有大量用 Rust 编写的工具，并没有表现出显著的速度优势。真正有意思的问题在于：究竟是哪些设计决策带来了这种差异。

Charlie Marsh 在 Jane Street 的一次演讲（Jane Street talk）以及一篇来自 Xebia 的工程深度解析（Xebia engineering deep-dive）已经很好地覆盖了技术细节。更值得关注的，是其中的设计选择：哪些标准让“快速路径”成为可能，uv 放弃了哪些 pip 所支持的特性，以及哪些优化其实完全不依赖 Rust。

使 uv 成为可能的标准

pip 的缓慢并不是实现层面的失败。多年来，Python 的打包体系必须通过执行代码才能知道一个包依赖什么。

问题出在 setup.py 上。你无法在不运行 setup 脚本的情况下知道一个包的依赖；但你又无法在不先安装构建依赖的情况下运行 setup 脚本。PEP 518 在 2016 年明确指出了这一点：“你无法在不知道依赖的情况下执行 setup.py 文件，但目前又没有一种标准化的方式，可以在不执行 setup.py 文件的前提下，以自动化手段获知这些依赖。”

这种“先有鸡还是先有蛋”的问题，迫使 pip 只能采取一条低效且危险的路径：下载包、执行不受信任的代码、失败、安装缺失的构建工具、再重试。每一次安装，都可能演变成一连串子进程的启动和任意代码的执行。安装一个源码分发包，本质上就像是多了几步的 curl | bash。

解决方案是分阶段出现的：

• PEP 518（2016）引入了 pyproject.toml，为包提供了一个无需执行代码即可声明构建依赖的位置。TOML 格式借鉴自 Rust 的 Cargo，这也让“一个 Rust 工具回过头来修复 Python 打包体系”这件事看起来不那么像巧合。
• PEP 517（2017）将构建前端与后端解耦，使 pip 不再需要理解 setuptools 的内部细节。
• PEP 621（2020）标准化了 [project] 表，使依赖信息可以通过解析 TOML 获取，而不是运行 Python 代码。
• PEP 658（2022）将包的元数据直接放入 Simple Repository API，使解析器甚至无需下载 wheel 就能获取依赖信息。

PEP 658 于 2023 年 5 月 在 PyPI 上正式上线；uv 则在 2024 年 2 月 发布。uv 之所以能够如此之快，是因为整个生态系统终于具备了支撑这种速度的基础设施。像 uv 这样的工具在 2020 年是不可能发布的——当时这些标准还不存在。

其他生态系统更早就解决了这个问题。Cargo 从一开始就拥有静态元数据；npm 的 package.json 是声明式的。Python 的打包标准，直到最近才终于在这一点上追平了它们。

uv 放弃了什么

速度来自于删减。你不需要走的每一条代码路径，都是你不必等待的时间。

uv 的兼容性文档本质上就是一份“它不做什么”的清单：

不支持 .egg。
Egg 是早于 wheel 的二进制分发格式。pip 仍然要处理它们；uv 则干脆完全不支持。这个格式早在十多年前就已经过时了。

不支持 pip.conf。
uv 完全忽略 pip 的配置文件：不解析、不读取环境变量、不从系统级或用户级位置继承配置。

默认不进行字节码编译。
pip 在安装时会将 .py 文件编译为 .pyc。uv 跳过了这一步，从而为每次安装节省时间。如果你需要，也可以显式开启。

强制使用虚拟环境。
pip 默认允许直接安装到系统 Python。uv 则反其道而行，在没有显式标志的情况下拒绝修改系统 Python。这消除了一整类权限检查和安全相关的代码。

更严格地执行规范。
pip 会接受一些在技术上违反打包规范的畸形包；uv 会直接拒绝。容忍度越低，回退逻辑就越少。

忽略 requires-python 的上界。
当一个包声明需要 python<4.0 时，uv 会忽略这个上界，只检查下界。这极大地减少了解析器的回溯，因为这些上界几乎总是错误的。包作者声明 python<4.0，通常只是因为还没在 Python 4 上测试过，而不是因为真的会出问题。这种约束是防御性的，而非预测性的。

默认“第一个索引即胜出”。
当配置了多个包索引时，pip 会逐一检查所有索引；uv 则在第一个找到该包的索引处立即停止。这既可以防止依赖混淆攻击，也避免了多余的网络请求。

上述每一项，都是 pip 必须执行而 uv 不需要执行的一条代码路径。

在这里，Rust 才真正发挥作用

有些优化确实必须依赖 Rust 才能实现：

零拷贝反序列化。
uv 使用 rkyv 对缓存数据进行反序列化，而无需复制数据。其数据格式本身就是内存中的表示形式。其他语言中也有类似 FlatBuffers 这样的库可以做到这一点，但 rkyv 与 Rust 的类型系统深度集成。1

线程级并行。
Python 的 GIL 迫使并行工作只能通过多进程来完成，这会带来进程间通信的开销以及数据复制。Rust 可以在原生线程之间并行执行，并共享内存而无需序列化边界。这在依赖解析阶段尤为重要，因为求解器需要探索大量版本组合。1

没有解释器启动成本。
pip 每次启动子进程，都要付出 Python 解释器启动的代价；而 uv 是一个单一的静态二进制文件，没有需要初始化的运行时。

紧凑的版本表示。
在可能的情况下，uv 会将版本号打包为 u64 整数，使比较和哈希操作非常高效。超过 90% 的版本号都能放入一个 u64 中。这是一种微优化，但在数百万次比较中会不断累积效果。

这些都是实实在在的优势。但与放弃遗留支持、并充分利用现代标准所带来的架构层收益相比，它们反而显得次要一些。

设计优先于语言

uv 之所以快，并不是因为它用什么语言写成，而是因为它选择了不做什么。PEP 518、517、621 和 658 所推动的标准化工作，使得高速的包管理成为可能；而放弃 egg、pip.conf 以及宽松（但复杂）的解析策略，则让这种速度真正落地。Rust 只是让它在此基础上又快了一点。

从技术上讲，pip 明天就可以实现并行下载、全局缓存，以及仅基于元数据的依赖解析。但它并没有这样做，主要原因在于：对过去十五年各种边缘情况的向后兼容性，始终优先于激进的重构。这也意味着，pip 注定会比那些在现代假设之上重新出发的工具更慢。

其他包管理器可以从中学到的经验是：使用静态元数据；在发现依赖时避免执行代码；在下载之前就一次性完成完整的依赖解析。Cargo 和 npm 多年来一直以这种方式运作。如果你的生态系统必须运行任意代码才能知道一个包需要什么，那你在设计层面上就已经输了。

前段时间突发奇想，从更理论的角度审视AI智能体，于是和Gemini进行了一番对话。

我的提问是：从系统论、控制论、信息论的视角，深度探讨AI智能体

以下是Gemini的回答：

这是一个非常深刻且宏大的视角。系统论（Systems Theory）、控制论（Cybernetics）和信息论（Information Theory），也就是经典的“老三论”（SCI），是研究复杂系统的基石。

将AI智能体（AI Agent）置于这三个维度下审视，我们不再将其视为单纯的代码或大模型，而是一个 “在开放环境中，通过信息交互维持自身有序性，并利用反馈机制实现目标的复杂系统”。

以下是基于这三个维度的深度探讨：

一、 系统论视角：智能体的解剖与涌现

核心隐喻：AI Agent 是一个开放的有机整体，而非孤立的算法。

在系统论看来，整体大于部分之和。AI Agent 不是单纯的大语言模型（LLM），LLM 只是它的“大脑”。Agent 是一个由多个组件构成的功能系统。

1. 结构功能主义：从 LLM 到 Agent 的系统架构

一个典型的 AI Agent 系统架构（如 AutoGPT 或 LangChain 架构）完全符合系统论的定义：

• 要素（Elements）：

  • 中枢（LLM）： 负责推理、规划和决策。

  • 感知（Perception）： 多模态输入（文本、视觉、音频）。

  • 记忆（Memory）： 短期记忆（Context Window）和长期记忆（Vector Database）。

  • 行动（Tools/Action）： API调用、搜索、代码执行。

  • 结构（Structure）： 这些要素通过特定的 Prompt Engineering 和 Orchestration（编排）逻辑连接，形成“感知-规划-行动-观察”的链条。

2. 开放系统与环境交互

系统论强调系统与环境的边界。传统的机器学习模型是封闭的（输入->输出），而 AI Agent 是开放系统（Open System）。

• Agent 必须存在于一个“环境”中（操作系统、浏览器、游戏世界）。
• 它通过输入输出接口与环境进行物质（数据）和能量（算力）的交换，从而改变环境状态。

3. 涌现性（Emergence）：多智能体系统

当多个 AI Agent 协作时（如斯坦福的虚拟小镇实验），单个 Agent 的简单规则（“我要去买咖啡”）在系统层面涌现出了复杂的社会行为（选举、派对、谣言传播）。这是系统论中 “涌现” 的经典体现——宏观智能来自于微观交互。

系统论洞见： AI Agent 的核心竞争力不在于模型参数有多大（部分），而在于其组件（记忆、工具、规划）如何通过架构设计形成高效的整体协同。

二、 控制论视角：目标、反馈与自适应

核心隐喻：AI Agent 是一个拥有“目的”并能自我修正的舵手。

控制论的核心是反馈（Feedback）和控制（Control）。在这一视角下，AI Agent 被视为一个目的论系统（Teleological System），即它的行为是为了达成某种特定的目标状态。

1. 负反馈调节：从错误中修正

这是 Agent 与 Chatbot 的本质区别。

• 开环系统（Chatbot）： 用户提问 -> 模型回答。结束。
• 闭环系统（Agent）： 设定目标（“帮我订票”） -> 行动 -> 观察结果（Feedback） -> 结果不符 -> 修正行动 -> 再次尝试 -> 达成目标。
• 这种**OODA循环（Observe-Orient-Decide-Act）**是控制论在 AI Agent 中的直接投射。Agent 通过不断的负反馈（误差修正）来逼近目标。

2. 黑箱与白箱控制

• LLM 本身在很大程度上是一个黑箱（Black Box），我们难以解释其内部具体的神经元触发路径。
• 但 AI Agent 的架构设计试图在黑箱之外构建白箱控制逻辑（White Box Logic）。例如，通过 Chain-of-Thought (CoT) 强制模型输出中间步骤，或者通过 ReAct (Reasoning + Acting) 框架，让思维过程显性化，从而变得可控。

3. 稳态与失控

控制论关注系统的稳定性。

• 稳态（Homeostasis）： Agent 需要在长对话或复杂任务中保持“人设”或“目标”不漂移。
• 正反馈导致崩溃： 幻觉（Hallucination）往往是一种正反馈循环。模型生成了一个错误，后续的推理基于这个错误继续生成，导致误差放大，最终系统失控。优秀的 Agent 架构必须包含“看门狗”机制来切断这种正反馈。

控制论洞见： AI Agent 的强大在于其鲁棒性。一个好的 Agent 不是因为它从不犯错，而是因为它拥有强大的反馈回路，能够检测并修正错误。

三、 信息论视角：熵减与不确定性消除

核心隐喻：AI Agent 是通过处理信息来对抗无序（熵）的机器。

香农的信息论关注信息的量化、传输和处理。在这一视角下，AI Agent 的本质是信息处理器，其终极目标是负熵（Negative Entropy）——即在混乱的环境中建立秩序。

1. 消除不确定性（Uncertainty Reduction）

• 用户的任务通常是模糊的（高熵）。
• Agent 的工作流就是通过多轮交互、搜索确认、推理，不断排除可能性的过程，将高熵的模糊指令转化为低熵的确切行动（如具体的 API 调用参数）。
• 公式化理解：Agent 的价值等于其消除的**信息熵（Information Entropy）**总量：

Agent 通过观察（获取信息）改变概率分布 ，使系统确定性增加。

2. 信道容量与压缩

• 上下文窗口（Context Window）： 这是 Agent 的信道容量（Channel Capacity）限制。Agent 必须学会“有损压缩”，将长期记忆中的关键信息提取摘要，放入有限的 Context Window 中。
• Prompt Engineering： 从信息论角度看，Prompt 是对任务信息的编码（Encoding），而 LLM 的输出是解码（Decoding）。优秀的 Prompt 设计就是为了最大化信噪比（Signal-to-Noise Ratio），减少模型对噪声的误解。

3. 幻觉作为“噪声”

在通信模型中，幻觉可以被视为信道中的噪声（Noise）。

• 当模型内部知识不足（数据缺失）或上下文过长（信号衰减）时，噪声占比上升，Agent 就会开始“一本正经地胡说八道”。
• RAG（检索增强生成）技术的本质，就是引入外部高保真信源，以提高输入端的信噪比。

信息论洞见： AI Agent 的瓶颈往往在于带宽（记忆检索的效率、上下文长度）和信噪比。提升 Agent 能力的关键在于更高效的信息编码和更精准的噪声过滤。

四、 综合图谱：三论合一的 AI Agent

我们可以用一个综合模型来概括这三个视角：

总结

从“老三论”的视角来看，AI智能体是人类试图创造的一种“数字生命体”雏形：

1. 它以系统的形式存在，具备结构完整性；
2. 它通过控制回路与环境交互，表现出目的性；
3. 它以信息处理为能量，通过降低熵值来产出价值。

这种视角超越了单纯的代码工程，它告诉我们：要构建更强大的 AGI（通用人工智能），我们不能只盯着改进 Transformer 的算法（微观优化），更需要设计优良的反馈系统（控制论）和高效的信息流转架构（系统论）。

VS Code 的 Github Copilot 拓展最近的更新带来了对 Claude Skills 的实验性支持，我简单尝试了一下，使用 Claude 官方的前端设计 Skill开发了一个赛博朋克风格的个人网站。 项目初始化和代码编辑全程由 AI 自动完成，我只是手工批准了一些关键步骤。
仓库地址
感言：AI生成的网页终于不是千篇一律的渐变紫背景了。

附 Frotend Design Skill 的 skill.md：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

---
name: frontend-design
description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
license: Complete terms in LICENSE.txt
---

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.

## Design Thinking

Before coding, understand the context and commit to a BOLD aesthetic direction:

- **Purpose**: What problem does this interface solve? Who uses it?
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
- **Constraints**: Technical requirements (framework, performance, accessibility).
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?

**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.

Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:

- Production-grade and functional
- Visually striking and memorable
- Cohesive with a clear aesthetic point-of-view
- Meticulously refined in every detail

## Frontend Aesthetics Guidelines

Focus on:

- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.

NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.

**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.

Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.