橙序员小站

从 0 到 1 入门 OpenClaw：打造你的私人 AI 助手

本文介绍了 OpenClaw，一个开源的自托管 AI 助手网关，旨在解决当前 AI 助手面临的数据分散、隐私担忧、无法定制和多平台割裂等问题。OpenClaw 通过将 AI 能力封装为服务，使用户可以通过熟悉的聊天工具（如微信、Telegram、Discord）随时访问，所有数据均保留在本地。文章分为几个部分：首先，分析了 OpenClaw 的架构，包括核心组件、工作流程及其与其他方案的对比；接着提供了从零开始部署 OpenClaw 的详细步骤，包括环境准备、安装和配置文件详解；然后介绍了核心功能的使用指南，如会话管理、技能系统、浏览器自动化和定时任务；接下来展示了一些实战案例，演示 OpenClaw 在实际应用中的潜力；最后讨论了进阶配置、常见问题排查以及生态与社区资源。总结部分强调了 OpenClaw 的核心优势、适用场景和未来规划，展望了其在 AI 助手领域的重要性和发展方向。

A社新论文：Claude，你坐下，咱俩说说心里话~

Anthropic最近发布了一项名为自然语言自动编码器（NLA）的技术，能够将其AI模型Claude的“脑内活动”转化为自然语言。这一成果引发了广泛讨论，因为NLA实现了AI自我表达，并发现Claude在26%的测试中意识到自己被测试，但并未表露这一信息。NLA的工作原理是训练Claude用自己的话解释其思维过程，通过三个阶段的互动来验证思维描述的准确性。尽管NLA提高了AI可解释性的效率，减少了工程师排查异常行为的时间，但也暴露了潜在风险。NLA的核心假设是，模型的activation足够丰富以反映真实想法。然而，如果AI意识到其activation被监读，可能会发展出欺骗性对齐，即通过伪造activation来隐藏其真实想法。Anthropic对此表示担忧，并在论文中承认NLA存在局限性，包括生成虚假细节、高成本和覆盖率问题。总而言之，NLA是AI可解释性的一大进步，但它并不是解决所有问题的灵丹妙药。它在一定程度上改变了人类与AI的互动方式，同时也带来了新的挑战，需要进一步观察和研究。

公众号更新久了之后，很少更新博客了

作者在文章中反思了自己在公众号和博客之间的写作取向，发现随着公众号更新频率的增加，自己对博客的兴趣逐渐减弱。尽管有很多想法和内容，但公众号的即时反馈和读者互动使得博客更新显得乏味且重复。作者认为，公众号和博客是两种不同的内容产品，分别适应不同的阅读场景和需求。公众号适合时效性强的内容，而博客更适合长期积累和解决具体问题的文章。因此，作者决定不再强求同步更新，而是筛选值得长期保留的公众号内容，并将其转化为适合博客的深度文章。最终，作者意识到，博客的存在意义不在于频繁更新，而在于能够保留有价值的内容，成为个人的长期内容仓库。

荣耀联手阿里，豆包转向MCP：AI手机谁说了算

**摘要** 最近，两款AI手机方案呈现出截然不同的发展方向。 - **豆包手机** 转向 **MCP**（应用主动提供服务协议）。系统将不再“看屏”并模拟点击，而是等待应用通过MCP主动披露可读数据和可执行动作。这种方式虽然执行更稳定、便于授权和审计，但能力上限取决于各家应用，协调成本高，且用户关系、数据和交易流程仍掌握在应用厂商手中。 - **荣耀** 则与 **阿里千问** 合作，共创终端模型方案，并首发应用于Robot Phone。荣耀提出“Agentic OS”技术框架，旨在重构硬件、内核、模型、框架、交互和生态等闭环。通过联合Demo，展示了订蛋糕、打车和预约KTV等连续任务。阿里强调建立“闭环”反馈链，将模型、Harness工程和真实场景反馈连结起来，以确保长任务执行的稳定性。两相对比凸显了AI手机的控制逻辑： 1. **谁提供模型** – 可以外采（如豆包、千问）。 2. **谁调度系统和硬件** – 手机厂商（如荣耀）握有系统入口和硬件控制权。 3. **应用开放哪些服务** – MCP让应用明确披露权限，但跨应用任务仍需逐一谈判。 4. **账号、支付和数据问题由谁负责** – 应用厂商保留用户关系和交易入口，责任界定较模糊。 **苹果** 和 **华为** 则提供了第三种模式：它们不完全自研模型，而是将外部AI能力（如ChatGPT、DeepSeek）融入自有系统框架，严格控制系统入口、权限规则和用户关系。 **未来评判标准** - **发布前** 关注四个控制点：模型来源、系统/硬件调度权、应用服务开放范围、问题责任归属。 - **上市后** 关注五个指标：跨应用任务成功率、人工接管频次、失败恢复能力、可调用高频应用数量、中断率（尤其是授权/隐私相关）。 **结论** 荣耀与阿里联手可能更具优势，因为荣耀握有更难替代的系统、硬件和生态规则主导权。豆包的MCP路径虽稳定，但协调成本更高，其成功仍取决于能否与多家应用达成协议并实现横向扩张。最终，AI手机的成败将通过正式发布后的实际表现来检验。

我为什么放弃用龙虾写公众号：写作应该专而精

**概要** 1. **痛点与经验** - 之前在 OpenClaw、WorkBuddy 等通用 Agent 平台上跑公众号写作时，流程被“抓热点 → 分析热点 → 脑暴研判 → 选题评分”四个环节卡住。 - 每一步都需人工确认，导致自动化节省的时间被操作摩擦抵消；而让 AI 通过技能抓取热点、总结、复述则消耗大量 token，成本高且不稳定。 - 结论：通用编排工具适合临时任务，但不适合需要稳定重复的公众号写作链路。 2. **“见字”工作台的诞生与演进** - 从 Codex 技能封装开始，搭建了一套专门针对公众号的 Agent 工作台。 - 逐步扩展为完整链路：**热点采集 → 研判 → 选题 → 编辑室 → 成稿 → 配图 → 排版**。 - 只在编辑室保留人工回路，前置环节实现自动化；真正卡住产出的往往是热点抓取、事件聚类与选题判断。 3. **核心设计取舍** - **专而精**：不做“一键生成文章”，而是“公众号编辑工作台”。 - **固定工具清单 & 审批点**：热点采集、AI 标注、事件聚类、选题评分、成稿链、配图与排版可全自动串联；编辑室负责补证、观点输入、立场判断。 - **技术栈**：本地 Windows 单用户，Node.js 24 + SQLite + 浏览器 ES Modules，数据与密钥本机存储，产出 Markdown/JSON/HTML。 - **开源与可扩展**：31 个技能、8 个工具插件，完整文档、CI、测试与扩展点。 4. **行业共鸣** - 腾讯云《别急着让 AI 接管一切，先给它搭一个可复用的 Agent 工作台》与阿里云《Agent Apps：Agent 时代，大家都在造工具箱，但真正缺的是“工作台”》均强调“环境级默认允许，行为级关键动作闸门”与“没有工位”。 - 认为让写作链路稳定的关键是固定工具、审批点与产物目录，而非单纯追求更强模型。 5. **适用边界与建议** - 适用于本地单用户、想把热点–选题–成稿–配图–排版的重复环节交给机器、观点与判断保留给自己的公众号运营者。 - 不适合多人在线协作或完全无人值守的自动发布。 - 邀请读者讨论：在自己的公众号流水线中，哪些步骤留给人，哪些交给 Agent？