Agent

如果把 Claude Tag 只理解为 Slack 机器人，会错过它最重要的产品变化。它把频道变成了一个可授权、可记忆、可持续运行的 Agent 空间：团队共享同一个执行者，任务在 Anthropic 托管的线程级沙箱中异步完成，外部凭证由 Agent Proxy 在边界注入，结果回到公开线程并留下可追溯记录。Claude Tag 官方文档 已经把这些机制写得相当具体。 ...

一次交流里，我卡在一句看似简单的话上：“我知道 Agent 的体感边界，但是不知道 Agent 具体的定义怎么样说。” 我能判断一个固定路径的 workflow 不太像 Agent，也能看出一个会根据工具结果改计划、必要时暂停或移交的系统更像 Agent。可当对方等我给出一句没有漏洞的定义时，我发现脑中的东西不是一句话。它更像许多正例、反例、相邻概念和行动后果叠出来的判别器。 ...

“常识就是本质吗？”我最近连续拿几个行业做推演时，最先卡在了这个问题上。看完 22 家前沿 AI 团队、70 余位公开人物的作品链后，我反复遇到几种动作：围绕一个长期命题积累，先写清怎样才算合格，让论文、代码和产品连续留下作品，再把生产失败送回下一轮。可这些动作仍没有回答：面对传统行业，我从哪里开始判断，才能避免拿着新技术寻找伪需求？ ...

本文是一场思想实验式模拟访谈。受访者由认知神经科学与 AI 记忆系统工程视角组合而成，不代表任何真实专家的原话。 2026 年 3 月，我在一条笔记里写：AI 时代，也许忘记比记忆更重要。 ...

Open Design 很容易被名字带偏。这个词也指更早的开放式设计运动，但本文讨论的是 nexu-io/open-design ：一个把 Coding Agent 组织成设计生产系统的开源工作区。 它不是模型，也不只是一个出图工具。更准确地说，它是一套 harness——给能力加上边界、流程与反馈回路的工作台。它为 Agent 准备可控的词汇、可复用的工作方法、视觉约束、工件迭代环，以及检查结果的地方。模型和操作者依然决定质量上限，Open Design 改善的是从意图走到成品的那段路。 ...

先把“技巧清单”放到一边 我最初想写一篇 Boris Cherny 用法合集。问题是，社交媒体里的经验会随模型、版本和套餐变化；粉丝站又常把个人观点、尚未公开的功能和统计数字混在一起。今天看起来锋利的结论，几个月后可能只剩一个漂亮的句子。 ...

用得越熟，为什么反而越累 先说一个我自己撞了很久才想明白的怪现象。 刚开始用 Claude Code 的时候，效率提升是肉眼可见的：一个下午干完过去两天的活。用熟之后，效率还在涨，但一天结束时的疲惫感也在涨——因为我整天都在做同一件事：看它跑完、判断对不对、想下一句该说什么、再敲回车。 ...

一个早上，和三件不该存在的东西 有一天早上我起来，泡咖啡，打开笔记本，看到夜里跑的几个 agent 都停在了完成状态：一个给我的小工具加了完整的多语言支持，中英日三套文案，抽了 i18n 层；一个给博客做了阅读进度统计；一个把我半年前写的 CLI 重构成了插件架构。代码都很干净，测试都是绿的。 ...

这是《超级个体的装备栈》系列的第二篇。如果你还没读过总纲 ，建议先读那篇——这篇的所有判断都建立在那篇提出的标准之上：一层装备的进步，是只帮你，还是同时帮你所有对手。 ...

第十五份清单，让我换了一个问题 半年里，我认真读过二三十份「AI 时代超级个体装备清单」。读到第十五份左右时，一件事越来越扎眼：这些清单彼此之间的差异，远小于它们各自许诺的竞争优势。 ...

我决定做一个面向程序员的开发机体检 skill，代号 devbox-doctor。它只读扫描你的 Mac，把应用、包管理器、配置接管点、常驻资源和可能的卸载残留整理成事实；模型只负责解释证据并提出下一步，不能把“看起来像”变成删除命令。最终交付是一份能复核、能降级、能说明自己哪里不知道的体检报告。这篇文章记录它的设计，也记录几处最容易写得漂亮、做得危险的地方。 ...

一套有价值的 Skill，核心不在 prompt 多精妙，而在三件事划分得多干净：确定性的工作交给代码，语义判断交给模型，执行确认交还给人，再用结构化契约把三者缝起来。这个结论来自我最近拆解的一个存储清理 Skill。删文件是 Agent 的高风险能力，而它能让我从「本能警惕」走到「愿意确认」，靠的是设计，不是信任。 ...

框架立完之后，我发现自己没有「第一现场」 「从信息到创作」五篇写完，框架是立住了：信息采集降噪，记录沉淀半成品，知识结构化成能力，创作面向受众重组。但写完第三层·知识 里那句「知识库是你和 AI 共用的第一现场」之后，我一直有点心虚—— ...

先说这件事本身 把一座写了四年、积累了 120 多篇文章的博客，从内容架构到运营方式全部重新组装一遍，需要多大的团队？ 我今年上半年给出了自己的答案：一个人，带一队分工明确的 Agent。 这里的"一队"不是一个固定数字，也不是七八个永远在线的数字员工；它是我对 Claude Code、Codex、GitHub Actions 中的 Claude 任务，以及临时评审会话的统称。截至 2026 年 7 月，仓库里能数清的是七个 Claude skills、四条以 seo- 命名的工作流和若干按需启动的会话。人负责判断、边界和签字，Agent 承担范围明确、可以验收的执行。新版就是你现在看到的 cubxxw.com ——它不只是一次改版，而是把"博客"这个东西从一个静态网站，改造成了一个会生成日报、准备修复 PR、对外提供检索接口的系统。 ...

假如今天你要给自己选一个 AI Agent 的方向下注，你最该先问的问题是什么？ 多数人问的是"这个能不能做出来"。但在 2026 年，许多应用的首要瓶颈已不再是模型能力，做出 demo 也不再稀缺。真正该问的，是另一个更冷的问题：“为什么这么大的机会，别人还没把它做死？” ...

假设你现在真的有一个 agent，能把一件事从头做到尾——拉数据、写代码、跑测试、发 PR、改文档，一条龙。它不需要你在旁边一句一句喂提示词。你晚上把任务丢给它，去睡觉。 ...

最危险的简报，可能一条内容都没有 早上打开每日简报，页面上显示 0 条新内容。也许昨夜确实风平浪静；也可能是 RSS 路由坏了、API 开始返回空页，或者凭据在凌晨过期。从读者这一端看，这几种完全不同的状态只有同一个样子：安静。 ...

一个人究竟养得起多大的 Agent 舰队？ 这个问题听起来像是在数进程，其实是在找一个错误的单位。一个 Agent 可能只抽取一段文字，也可能搜索二十分钟，或者经过八十次工具调用才完成一次仓库重构。真正有意义的单位不是“Agent 个数”，而是一个被验收的任务，以及它背后的输入、输出、工具、重试和人工善后。 ...

一个反直觉的信号：它开始反过来提示你 假设有一天，你打开工作台，Agent 没有等你输入下一条命令，而是先说： 我注意到昨天那份方案的第三节还没有收尾。我按你上周的口径起了一个草稿，现在要看吗？ ...

如果你搭一个 AI，让它追某个领域的论文、发布、benchmark、观点和 changelog，它到底能替你走到哪一步？从 2026 年 1 月到 6 月，我持续试用了自己能接触到的一批资讯聚合、页面监控和自动简报工具。这个样本不覆盖市场上的全部产品，也不是严格的横向测评；它只是我在同一套技术资讯任务上的长期观察。结论是：AI 很擅长搬运和整理；但缺少用户目标、工作上下文与结果反馈时，它不能可靠替代最终判断。 ...

一年过去了，为什么大多数人的 AI 还停在原地 过去一年，写文案、翻译、总结和分析都用上了 AI。但诚实地问一句：它真的接管了业务环节，还是每次仍由你重新交代背景、判断输出、决定下一步？ 模型变聪明了，反复切换上下文和担责任的人往往没变。 ...

聊了很久，手里留下了什么 我也有过这样的晚上：本来只想把一个选题想清楚，结果和 AI 从标题聊到商业模式，又从商业模式聊到人生。对话很顺，窗口关掉之后，文章仍是一片空白。 这不说明对话无用。它只提醒我：探索和执行是两种不同的工作。 ...

「能跑」不等于「可靠」 大多数人搭个人 AI 系统时，第一条验收标准是：能不能跑？ 能写出一篇文章，能改完一段代码，能把十页资料压成一页，看起来就算完成了。但用久以后，真正折磨人的是无声的错误：结构工整，语气笃定，结论却悄悄偏离了事实。 ...

先别造宫殿，先跑通一条路 很多笔记系统的问题，不是功能太少，而是入口、目录、插件和自动化同时开工。最后系统很漂亮，自己却不敢改；AI 一旦批量重命名，更不知道哪里出了错。 ...

越堆越大，越来越没用 到第三层了。信息被采集降噪，记录被写下、精修成半成品——现在要回答的是：怎么把这些半成品，变成真正的知识？ 先说知识的定义。知识是和你相关的、结构化的、能反复调用的东西：某种思维模型、某几项技能、某套方法论，还有你的判断、定位、价值观。它的关键词是可复用，它解决的是你自己的问题。 ...

open-lovable 看起来像一句很短的产品承诺：给它一个网址，得到一个可继续修改的 React 应用。真正值得读的却不是生成结果，而是它怎样把抓取、模型输出和不可信代码执行接成一条可控链路。 ...

「Software is eating the world.」 —— Marc Andreessen, 2011 「Now, AI is eating software, and the question for the rest of us is: what’s left for one human, alone, in front of a screen?」 —— 我于 2026 年的某个凌晨，在台灯下问自己。 ...

架构图是一张承诺清单；源码审计要问的是，其中哪些箭头已经有了重量。 这篇文章的旧版把 Relay 写成一个公开的开源方案，还说它的 Agent 层尚未开工。到 2026 年 7 月 31 日，这两个判断都不再成立：旧文引用的公开 GitHub 地址返回 404，而我能够核对的是一份私有本地检出。 ...

上下文工程（Context Engineering）是在 LLM 每一次推理时，对进入上下文窗口的最优 token 集合——系统提示、检索文档、对话历史、工具定义与记忆——进行筛选、排序与淘汰的一整套工程策略。 它与提示词工程的区别一句话讲清：提示词工程优化「一句话的措辞」，上下文工程优化「整扇窗口的布线」。这个定义来自 Anthropic 的工程文章，Karpathy 也公开背书了这次改名。下文把这门正在成形的学科完整拆开。 ...

「Agent loop 是 10 行代码，Agent engineering 是 10 万行代码。」 这句话不是代码审计结论，更像一把拆系统的刀。它戳破了一个常见错觉：把 prompt 写好、把 LLM API 调通，只能证明 loop 能转；要让系统在无人值守时仍可恢复、可追踪、可约束，主要工作在 loop 外。 ...