Agent

写在前面：颓废的表面，和底下的高密度 六月我从老挝回到了深圳。 如果只看状态，这是一个颓废的月份。具体是什么样子呢——天黑了才有点精神，每天熬到凌晨两三点，靠一部接一部的短剧短片把自己哄睡；白天醒来，窗外是深圳灰白的天，连出门的力气都凑不齐，想着是不是跟天气有关，但其实自己心里清楚不全是。每天都在心里跟自己谈判：明天一定早起、一定自律、一定开始干活——然后第二天又输给那个赖在床上的自己。身体是虚的，那种虚不是累，是一种被抽空之后的空转。烦恼很多，但说不出具体是哪一件。 ...

系统 A 有十二个 Agent、长期记忆、云端电脑、事件日志和自动恢复。 系统 B 只做一次 document → structured candidate，把结果放进表单，等人核对原件后再保存。 ...

凌晨两点，Agent 准备给一个 GitHub issue 添加“修复已完成”的标签。 ActionEvent 已经写进日志。GitHub API 也返回了 200。就在 SDK 把结果包装成 ObservationEvent 之前，进程崩溃。 重启以后，历史里只剩一条没有 observation 的 action。 ...

法庭里坐着九位证人。 四位负责市场、情绪、新闻与基本面；两位分别坚持看多和看空；三位从激进、中性与保守的风险偏好发言。最后还有研究经理、交易员和组合经理逐层裁决。 ...

渲染命令退出码是 0。 MP4 文件存在，容器可被 ffprobe 读取，render_report 也符合 JSON Schema。流水线甚至可能给出 pass，建议把成片交给用户。 ...

下面是一段完全合法的模型输出： { "merchant": "ACME", "total": "129.90", "currencyCode": "EUR", "issuedAt": "2026-07-03", "items": [] } 字段齐全，没有多余属性，金额能转成分，日期也能解析。 但原票据写的是 12.99 EUR，日期是 2026-07-08。 Schema 没有失败。模型没有报错。provider fallback 不会发生。缓存还会让这份结果下次继续出现。 ...

假设同一家公司有两个 Telegram bot：一个服务欧洲客户，一个服务美国客户。两个 bot 都把消息交给同一个 support agent，session 隔离策略写成了 per-channel-peer。 某个平台用户 ID 恰好同时出现在两个账号里。 ...

前一篇 n8n 入门 已经从 Manual Trigger → Edit Fields → IF 开始，讲过 Growth OS、受限 Agent、人工审批、operation ledger、结果回流和 alternatives。 ...

聊天产品最容易展示的完成标志，是最后一条 assistant message。 任务产品最危险的完成标志，也是最后一条 assistant message。 因为“已完成”可能只表示 Agent 停止运行。用户真正要验收的，也许是一份引用可靠的报告、一张字段齐全的数据表、一个能打开的网站、一段可以维护的代码，或一个下周仍在运行的 bot。只要价值单位从 reply 变成 work product，完成状态就必须离开聊天气泡，落到 artifact 和外部世界。 ...

第二个界面，往往才是一次 Agent 架构审查的开始。 只有 CLI 时，输入框可以直接调用 loop，命令结果可以直接刷进终端，审批状态也可以藏在某个局部变量里。等 IDE 侧栏、桌面端、自动化脚本和第三方客户端陆续出现，同一份内部状态会被复制成四套近似实现：它们对“当前任务是否结束”“这次 patch 属于哪个 turn”“批准以后还受不受 sandbox 限制”给出不同答案。 ...

Pi 默认只把四个工具交给模型：read、bash、edit、write。 它没有内置 Plan Mode、Todo、MCP、subagent、permission popup 或 background bash。读到这里，很容易把 Pi 写成一篇极简主义赞歌：四个工具足够，复杂框架都可以删掉。 ...

把“永远不要修改 .env”写进 CLAUDE.md，这条要求会进入 Claude 的上下文。它会影响模型的选择，却没有在文件系统前竖起一道墙。 同一句话若进入 PreToolUse Hook、permission deny rule 或 sandbox 文件规则，语义已经变了：它开始决定一次工具调用能否发生，或者一个 Bash 子进程实际能碰到什么。 ...

先别连接邮箱、CRM 或社媒账号。打开一张空白的 n8n 画布，只放三个节点： Manual Trigger → Edit Fields → IF 在 Edit Fields 里写入一条假的内容信号，让 IF 根据证据数量把它送进 True 或 False 分支。先把 evidence_count 设为 3 执行一次，再改成 1 执行一次。两条路线都跑对以后，你已经碰到了工作流自动化最重要的五件事：触发、结构化数据、规则、分支和执行记录。 ...

如果把 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 开始返回空页，或者凭据在凌晨过期。从读者这一端看，这几种完全不同的状态只有同一个样子：安静。 ...