Bojie Li (李博杰)
2026-02-06
【本报告及演示文稿完全使用 OpenClaw 基于今天刚发布的 Claude Opus 4.6 模型生成】
【《从 Moltbook 看 AI Agent 的权限、协作与雇佣》Slides 演示文稿】
摘要：2025 年末至 2026 年初，大语言模型（Large Language Model, LLM）驱动的自主代理（Autonomous Agent）经历了从实验室原型到全球性社会现象的剧变。OpenClaw 框架赋予代理操作系统级执行能力，Moltbook 社交网络吸引了超过 150 万个代理自发形成宗教与政治结构，RentAHuman.ai 则让代理首次以”雇主”身份进入现实劳动力市场。与此同时，MIT Media Lab 提出的认证委托框架、Google 主导的 Agent2Agent 协议以及清华大学 AgentSociety 万人级模拟器等研究工作，正在为这一新兴领域构建理论与技术基石。本报告系统综合三份独立调研报告及十余项补充文献，围绕 权限（Permission/Authority）、协作（Collaboration）和 雇佣（Employment）三大支柱，对 AI Agent 的认知架构、协议标准、经济行为、安全威胁与治理路径进行全景式深度分析。
2026-01-25
【本文整理自知乎回答，是一篇古法手敲、非 AI 生成的回答。】
人和模型一样，最重要的是 Context
本来昨天早上心情不太好，看了两篇 technical report，觉得几乎每篇知名的 technical report 里都有自己认识的人，自己却啥也没做出来。
听到 Jiayi Weng 访谈中的一段，大意是”我觉得第一个被 AI 替代的职业是 researcher，接下来被替代的是他这种 infra engineer，最难被替代的是 sales，因为要说服对面的人买单，AI 可能没那么容易说动人，需要人跟人之间的沟通。”
我一下子就开心了，因为我们做的就是跟人沟通谈判的事情啊，这事也没有想象的那么难，竟然 Jiayi Weng 这样的大佬都认为这事不太可能……我觉得一个解释就是 context。
2026-01-16
【下述内容为 AI 根据录音整理，未作任何修改】
2026-01-11
本文档提供了一系列精心设计的 AI Agent 实践课题，涵盖从简单到困难的三个难度层次。这些课题旨在帮助学生深入理解 AI Agent 的核心技术和设计模式，包括工具使用、多 Agent 协作、长期记忆管理、外部化学习等前沿主题。每个课题都包含明确的实验目的、详细的实验内容描述和具体的验收标准，确保学生能够通过实践掌握构建高级 AI Agent 系统的关键技能。
课题按难度分为三个层次。建议学生根据自身基础选择合适的课题，循序渐进地提升能力。
课题索引
难度：简单
- 使用代码生成工具提升数学与逻辑推理能力
- 自然语言交互的 ERP Agent
- 狼人杀 Agent
难度：中等
- 个人照片搜索引擎
- 智能视频剪辑
- PPT 生成 Agent
- 书籍翻译 Agent
- 同时从多个网站搜集信息的 Agent
难度：困难
- 更懂你的用户记忆
- 边打电话边用电脑的 Agent
- 越用越熟练的电脑操作 Agent
- 能创造 Agent 的 Agent
2026-01-04
我跟 AI 聊了三个小时，写了两篇读书笔记（为了测试 AI 能力，我故意没有对 AI 生成的内容做任何修改）。
2025-12-21
评课社区本月遭遇了一次持续近两周的存储性能问题，导致服务响应缓慢、用户体验下降。本文记录了问题的发现、排查和解决过程，涉及 NFS 性能、ZFS 日志、Proxmox VE 虚拟化存储配置等多个层面。
2025-12-20
（本文整理自 AWS re:Invent 2025 大会期间 Anthropic 团队的演讲与深度交流）
查看演讲 Slides (HTML), 下载 PDF 版本（注意这个 slides 不是 Anthropic 官方的，是我根据照片、录音自己总结的）
本文内容
Claude 已经足够聪明了——智能不是瓶颈，上下文（Context）才是。每个组织都有独特的工作流程、规范和知识体系，而 Claude 并不天然了解这些。本文整理了来自 Anthropic 的 Context Engineering 最佳实践，涵盖 Skills、Agent SDK、MCP、评估体系等核心主题，帮助你构建更高效的 AI 应用。
- 01 | Skills 技能系统 - 让 Claude 掌握组织专属知识
- 02 | Context Engineering 框架 - 优化 token 效用的四大支柱
- 03 | Context Window 与 Context Rot - 理解上下文限制与退化问题
- 04 | 工具设计最佳实践 - 构建强大工具的要素
- 05 | Claude Agent SDK - 构建生产就绪 Agent 的框架
- 06 | 子 Agent 配置最佳实践 - 自动调用与权限管理
- 07 | MCP（Model Context Protocol） - 标准化的工具连接协议
- 08 | 评估（Evaluations） - 评估的重要性与最佳实践
- 09 | 构建 Coding Agent 的经验 - 从 Claude Code 中学到的
- 10 | 生态系统协同 - Prompts、MCP、Skills、Subagents 如何协作
2025-12-20
（本文是笔者在 2025 年 12 月 20 日的首届智能体网络与应用创新大会上的受邀报告）
摘要
当前 Agent 的人机交互以文本为核心，但这偏离了人类认知的自然模式。从第一性原理看，人类最擅长的输出模态是语音（说话速度是打字的三倍），最擅长的输入模态是视觉。视觉不是文字，而是直观的 UI。
第一步是实现实时语音交互。传统 VAD-ASR-LLM-TTS 串行架构的问题在于必须等待用户说完才能开始思考，在思考完成前无法输出。通过 Interactive ReAct 持续思考机制，Agent 可以边听边想边说：在用户说话时就开始思考，在自己说话时继续深入推理，充分利用所有时间间隙。
第二步是在实时语音基础上扩展观察空间和动作空间。通过扩展 Observation Space（从语音输入到 Computer Use 视觉感知）和 Action Space（从语音输出到 UI 生成与电脑操作），Agent 就能够一边打电话一边操作现有电脑/手机的 GUI 界面，并生成动态 UI 与用户交互。生成式 UI 的一种实现路径是生成前端代码，当前 Claude 4.5 Sonnet 已达到门槛。另一种实现路径是生成图片，当前 Nano Banana Pro 也已接近门槛。
这正是电影 Her 中 Samantha 的实现路径。Samantha 作为操作系统，需要具备五项核心能力：能够与用户实时语音对话，能够代替用户打电话办事，能够帮用户操作传统电脑和手机，能够打通用户现有设备和在线服务中的数据，拥有自己的生成式 UI 界面，有强大的用户长期记忆以实现个性化的主动服务。
2025-12-19
（本文是笔者在 AWS re:Invent 2025 Beijing Meetup 上的受邀报告）
感谢 AWS 的邀请，让我有机会参加 AWS re:Invent 2025。在这次美国之行中，我不仅参加了这场全球顶级的技术大会，更有幸与 OpenAI、Anthropic、Google DeepMind 等硅谷顶级 AI 公司的多位一线从业者进行了深入交流，其中大多数观点都得到了不同公司专家的交叉验证。
从 Las Vegas 的 re:Invent 会场，到 San Diego 的 NeurIPS，再到湾区的 AI 公司，十几天的密集交流让我学到了非常多。主要包括以下几个方面：
AI 辅助编程（Vibe Coding）的实践经验： 分析了不同场景下效率提升的差异，从创业公司的 3-5 倍提效，到大厂和研究机构效果有限的原因。
基座模型公司的组织与资源配置： 分析了 Google、OpenAI、xAI、Anthropic 等公司的优劣势，包括算力资源、薪酬结构，以及模型团队与应用团队的合作现状。
Scaling Law 的一线视角： 一线研究员普遍认为 Scaling Law 并没有结束，与 Ilya Sutskever、Richard Sutton 等顶级科学家的公开言论存在分歧。工程方法可以解决 Sampling Efficiency 和 Generalization 问题，基座模型还有很大进步空间。
科学化的应用开发方法论： 介绍了顶级 AI 应用公司普遍采用的 Rubric-based Evaluation 体系。
Context Engineering 的核心技术： 讨论了应对 Context Rot 的三大技巧：动态系统提示、动态加载 Prompts（Skills）、Sub-Agents 与上下文总结。以及文件系统作为 Agent 交互总线的设计模式。
创业公司的战略选择： 基于资源和人才的现实约束，分析了创业公司应该避开的领域（通用 Benchmark）和应该专注的方向（垂直领域 + Context Engineering）。
2025-12-18
在上一篇文章《搭建免安装客户端的 IKEv2 隧道，解决 Cursor 地区限制》中，我们介绍了如何使用 IKEv2 三层隧道来绕过 Cursor 等软件的地理位置限制。虽然 IKEv2 方案具有免安装客户端的优势，但三层隧道本身存在一些固有的性能问题。
本文将介绍一种更高效的替代方案：使用 Clash Verge 的 TUN 模式 配合 VLESS 协议，在保持对应用透明的同时，避免三层隧道带来的性能损耗。
三层隧道的性能陷阱
上一篇文章中的 IKEv2 + VLESS/WebSocket 架构存在三个主要的性能问题：
- TCP over TCP：应用层 TCP 被封装在隧道的 TCP（WebSocket）中传输，两层 TCP 状态机相互干扰
- Head-of-Line Blocking：多个应用连接复用同一条隧道，一个连接的丢包会阻塞所有连接
- 长连接 QoS 限制：单一长连接容易被网络中间设备限速