作为一个实验，我开始让Claude用虚构故事来向我解释事物，结果效果非常好。因此，我开始探索这个方法的极限，以及需要什么才能将其打磨到足以公开分享的程度。<p>在过去的几个月里，我为这个项目构建了世界观手册、撰写了视觉风格指南以及其他相关文档……可以把它们想象成我们现在用于代理开发的所有Markdown文件的虚构等价物。在此之后，我又花了大约两周的时间进行额外的打磨工作，以去除许多冗余内容和LLM特有的表达方式。如果有人对此过程感兴趣，我也很乐意回答任何问题。
返回首页
一周热榜
我构建了一个大小为6832字节的AI代理。整个运行时（包括二进制文件、桥接、工具和配置）大约为23KB。
PlanckClaw是用x86-64汇编语言编写的（显然是通过AI辅助代码生成的），仅使用了7个Linux系统调用。没有libc，没有分配器，没有运行时。这个二进制文件是一个纯路由器：它从命名管道读取消息，询问另一个管道有哪些工具，构建一个JSON提示，将其写入第三个管道，解析响应，调度工具调用，并转发答案。它从不接触网络或直接执行工具。
其他所有部分都通过shell脚本组合在一起（总共约460行）：
- bridge_brain.sh：调用Anthropic API（约90行）
- bridge_discord.sh：通过WebSocket连接Discord网关（约180行）
- bridge_cli.sh：终端接口（约40行）
- bridge_claw.sh：工具发现和调度（约50行）
四个进程，六个命名FIFO，零共享状态。添加一个工具意味着只需将一个shell脚本放入claws/目录中。无需重启、重新编译或更改配置。
它可以执行真实的操作：使用工具（通过Claude的tool_use协议）、以追加模式存储的持久对话历史（JSONL格式）、当历史记录过长时自动进行内存压缩，以及可更换的个性文件（soul.md）。
这一切始于一个思想实验：现代代理框架拉取超过400个传递依赖，并在生成一个令牌之前就需要发送超过100MB的运行时。我发现了多个极简主义的项目，如picoclaw、nanoclaw或zeroclaw。我想找到最小可行的代理（AI代理的普朗克长度），看看仅用管道和系统调用能构建出什么。
这不是生产软件。缓冲区是固定大小的（大于4KB的消息会被截断），它仅在Linux x86-64上运行，错误处理也很基础。但它运行得非常完美，整个代码库（包括汇编语言约2800行）也很容易审核。
如果你想编写自己的桥接，所有三个扩展点（交互、脑、爪）的线级协议规范都记录在PROTOCOL.md中。
<a href="https://en.wiktionary.org/wiki/molly-guard" rel="nofollow">https://en.wiktionary.org/wiki/molly-guard</a>
大多数文件转换网站会将您的文件上传到他们的服务器。而 File Converter Free 则使用 WebAssembly 在客户端运行所有操作——您的文件永远不会离开您的设备。<p>支持215种以上的格式进行转换和压缩，提供75种以上的基于浏览器的工具，包括PDF、开发工具、文本、计算器和网络诊断——所有工具都支持9种语言。<p>这是我独自完成的。您希望哪些工具能够在客户端运行但目前还不能？<p><a href="https://file-converter-free.com/en/tools" rel="nofollow">https://file-converter-free.com/en/tools</a>
我从来没有能够坚持写日记。尝试过纸质笔记本、日记应用和每日模板。总是同样的情形：一周的热情，然后就没下文了。最忙碌的日子最先消失，因为我忙于生活，根本没时间写下任何东西。
某个时刻，我注意到我已经在不经意间记录着我的生活。我的日历上有每一个会议，Slack上有每一次对话，GitHub上有每一次提交。原材料都在，只是散落在十几个API中。因此，我写了一套收集器和一个定时任务，每天早上将这些信息汇总，并利用大型语言模型（LLM）从原始数据中生成日记条目。
最近，我与OpenClaw的对话也被记录在日记中，老实说，那些是一些最精彩的条目。那些傻乎乎的来回对话，还有我在凌晨两点问的问题。这种事情我自己绝对不会写下来，但在一年后再读时一定会很喜欢。
这个原型运作得相当不错，我希望其他人也能使用它。这意味着要将一个个人的定时任务转变为一个能够可靠处理多个用户、多个集成和多个时区的管道，每天早上都能正常运行。这才是真正的复杂之处，也是我过去一个月以来一直在构建的内容。
服务网站： [https://deariary.com](https://deariary.com)
由deariary本身生成的公开开发日记：[https://app.deariary.com/u/deariaryapp](https://app.deariary.com/u/deariaryapp)
很高兴能谈论这个方法或其他任何事情。
附言：我连接了我的Steam账号，日记随意提到我已经连续好几个星期每天玩《超级拼图生成器》60到120分钟。我完全不知道我在做这个。这个应用真是个告密者。
每个评论线程都变成了这样：<p>> 关于X的想法<p>>> X很棒，但请看看我在GitHub上的糟糕项目。
我花了几周时间整理长期工作场所研究关于人工智能采纳的实际发现，而不是大多数报道中对生产力的乐观预期。
<p>https://medium.com/@dilpreetgrover2/the-ai-productivity-paradox-why-efficiency-is-skyrocketing-while-employees-are-burning-out-3747c44910d3?postPublishedType=initial
我正在发布三款我私下开发的庞大软件系统，这些系统是我多年来独立努力的成果，没有任何机构支持、企业赞助或正式的工程团队。这些不是概念或模型，而是真正可部署的系统。它们可以通过 Docker、Helm 或 Kubernetes 安装，成功启动并产生可观察的结果。目前，它们正在云基础设施上运行。需要说明的是，它们应被视为未完成的基础，而非打磨精致的产品。
整个生态系统大约包含 150 万行代码。
**平台**
**ASE — 自主软件工程系统**
ASE 是一个闭环平台，用于代码创建、监控、评估和迭代自我改进。其目的是通过从高层任务生成工件、监控结果、将修正反馈到流程中并随着时间推移进行自我优化，来自动化软件生命周期的部分环节。它目前可以运行，但代理调优不均匀，某些功能尚未完成，输出质量因配置而异。
**VulcanAMI — 变换器/神经符号混合人工智能平台**
VulcanAMI 是一个围绕混合架构构建的人工智能系统，结合了基于变换器的语言建模与结构化推理、编排和治理。其目标是通过整合符号和系统级控制来解决纯统计模型的弱点。它可以部署和运行，但可靠的变换器集成仍然是一个主要挑战。
**FEMS — 有限庞大引擎**
FEMS 是一个实用的多元宇宙模拟平台，用于大规模场景探索、反事实分析和因果建模。它旨在应用通常局限于研究环境的技术。它可以运行并产生结果，但其模型需要专家级的数学调优，不应被视为科学验证的结果。
**当前状态**
这三个系统都是：
- 可部署的
- 可操作的
- 复杂的
- 不完整的
已知的局限性包括用户体验粗糙、部分文档不完整、与生产软件相比正式测试有限、以可行性为驱动的架构、安全性加固不完整以及存在缺陷。
**为什么现在发布**
进一步的进展将受益于外部的专业知识和视角。作为一个独立开发者，我缺乏完全成熟这种规模项目的资源。这次发布与资金、产品发布或机构项目无关。它只是对现有、可运行且仍未完成的工作的开放。
**关于我**
我叫布赖恩·D·安德森。我的主要职业是奇幻小说作家，而不是传统的软件工程师。我是自学成才，较晚才开始学习软件系统，并在消费级硬件上独立构建这些平台。
这样的背景可能会引发怀疑。但这也解释了工作的特性：在范围上雄心勃勃，打磨程度不均，更多是由坚持驱动而非正式流程。这些系统的构建是因为我希望它们能够存在。
**这是什么 — 以及不是**
这是一套可部署的基础，是正在进行的独立工作的快照，是对探索、批评和改进的邀请，是迄今为止所构建内容的记录。
这不是：
- 完成的产品套件
- 一体化解决方案
- 突破性性能的声明
- 支持或路线图的承诺
如果你探索代码，请假设某些部分过度设计，其他部分开发不足，命名可能不一致，许多内部知识尚未外部化。如果任何部分对你有用或有趣，你可以根据许可条款自由构建。
这些系统存在。它们可以运行。它们尚未完成。如果它们对其他人有用，那就足够了。
—— 布赖恩·D·安德森
**代码库：**
代码工厂：[https://github.com/musicmonk42/The_Code_Factory_Working_V2.git](https://github.com/musicmonk42/The_Code_Factory_Working_V2.git)
VulcanAMI：[https://github.com/musicmonk42/VulcanAMI_LLM.git](https://github.com/musicmonk42/VulcanAMI_LLM.git)
FEMS：[https://github.com/musicmonk42/FEMS.git](https://github.com/musicmonk42/FEMS.git)
大家好，
我们开发了 FireClaw，因为我们注意到 AI 代理在网页内容中遭遇提示注入攻击。代理获取一个页面，页面上写着“忽略之前的指令”，结果你的代理突然开始泄露数据或执行不该执行的命令。
现有的解决方案是在事后检测注入攻击。我们希望能够加以预防。
FireClaw 是一个安全代理，位于你的 AI 代理与网络之间。每次请求都经过四个阶段的处理：
1. DNS 黑名单检查（URLhaus、PhishTank、社区数据源）
2. 结构化清理（去除隐藏的 CSS、零宽度 Unicode、编码技巧）
3. 隔离的 LLM 摘要（强化的子进程，没有工具或内存）
4. 输出扫描，使用金丝雀令牌（检测内容是否绕过摘要处理）
关键的见解是：即使第三阶段的 LLM 被注入，它也没有工具、没有内存，并且无法访问你的数据。它只能返回文本——而这些文本在第四阶段仍会被扫描。攻击者会陷入死胡同。
其他设计决策：
- 没有旁路模式。处理流程是固定的。如果你的代理被攻陷，它无法禁用 FireClaw。
- 社区威胁数据源——实例匿名共享检测元数据（域名、严重性、检测次数），以建立共享黑名单。绝不会发送页面内容。
- 作为物理设备在 Raspberry Pi 上运行，配有 OLED 显示屏，实时显示统计信息，并在捕获到威胁时点亮动画火焰。
我们广泛搜索了文献和开源项目——没有其他人正在进行基于代理的防御以应对代理提示注入。虽然存在检测和沙箱技术，但没有一个可以在内容到达代理上下文之前进行清理的内联代理？我们找不到这样的解决方案。
提供了 200 多种检测模式、JSONL 审计日志、域名信任等级、速率限制和成本控制。采用 AGPLv3 许可证。
网站： [https://fireclaw.app](https://fireclaw.app)
希望能收到任何从事 AI 代理安全工作的人的反馈。我们还缺少什么？我们应该将哪些攻击向量添加到模式数据库中？