FirstIntent

We build agents that get things done. Intent first.

[Garry Tan @garrytan]

The next generation of young people who change the world will almost certainly be the people who are most adept at making long-running multi-stage multi-team agent tasks work extremely well, and at high volume and across every part of their personal and work lives.

[FirstIntent @firstintentdev]

single-agent-harness 已被商品化，此赛道面向创业者宣告结束。

[FirstIntent @firstintentdev]

loop 都在讨论， loop 的最大作用是消耗大量的 token。一个低价值的任务无法通过 loop 放大价值。tokenmaxing 是虚假繁荣，去寻找 ai 产生真正价值的地方吧

[FirstIntent @firstintentdev]

k8s sandbox crd，云上基础设施现成的，重点是 agent 治理

[陈成 @chenchengpro]

把桌面 Agent 搬上云，最先消失的是"信任边界"：沙箱每次冷启动、跟陌生人共享硬件、由定时器或别的 Agent 触发，跑的还是 LLM 根据可能被注入的 prompt 生成的代码。桌面框架白送的那些保证，云端全要重建。CREAO 做了几个月平台后，沉淀出两条真正区别于桌面框架的工程经验。

第一条：把"慢变化的用户环境"和"快变化的平台 runner"按所有权边界拆开。用户满意那一刻把环境冻结成 snapshot，保证周一和周五字节级一致——这是 pip 给不了的可复现性。但 snapshot 把用户环境和平台 runner 封在同一个镜像里，"环境不变"和"一天部署多次"直接打架。解法借鉴操作系统换内核不擦 home：从冻结 snapshot 启动后热替换 runner，node --check 验证语法、chattr 解锁覆盖再加锁、藏掉 chattr 二进制、清空 V8 compile cache 强制重载，整个 swap 约 300ms，成功后再 re-snapshot 折叠进用户镜像。

第二条：长期凭证绝不进沙箱。Agent 调 Slack/GitHub/用户自己的 API 时不持有 token，而是把请求发给跑在沙箱外的 API bridge，由 bridge 在 host 侧贴上 OAuth token 再转发，响应回来时 token 不进沙箱内存。Bridge 两层校验：网络层只接内网 IP，应用层校验每次 run 现签、scope 到具体 user/app/session、过期时间贴着本次 run 窗口的短期 JWT。哪怕 prompt injection 让 Agent 把 process.env 转发出去，攻击者拿到的也只是个内网才能用、随 run 失效的一次性 token，没有主密钥可偷。

底层模式其实就四条无例外坚持的属性：状态住沙箱、代码可热替换、凭证留 host、一条 executeAgent 管道同时承接 UI 点击 / cron / API，计费日志可观测信号完全一致，新增触发面只是加条路由而非改架构。最值得记下的诊断问题是：你在云平台持久化的每个 artifact，谁控制它的变更节奏？用户和平台都在改的同一份资产，迟早要为耦合付账。沿所有权边界把它切开，让两边各按自己的时钟更新。

[FirstIntent @firstintentdev]

工程师重度 使用 claude code 方式

[Matt Van Horn @mvanhorn]

https://t.co/95lFnAyw0e

[Movez @0xMovez]

Claude Code creator:

"I don’t prompt Claude anymore. What I mostly use now is loops. I create loops - they do the rest of my job."

In 24 minutes, Boris reveals his real daily Claude Code setup:

Claude + loops + routines + dynamic workflows

Worth more than a $500 vibe-coding course

[FirstIntent @firstintentdev]

这种算技术栈 skill 了

[GitHubDaily @GitHub_Daily]

做跨平台桌面应用，绕不开一个老问题，想兼顾效率和原生性能，往往会陷入两难。

在 GitHub 上看到一个开源解决方案 native-feel-skill，它把 Raycast 2.0 的技术方案拆解成了一套可复用的 AI Agent 技能。

安装后，当我们和 AI 讨论跨平台桌面架构时会自动激活，直接给出架构建议、问题诊断和优化方案。

GitHub：https://t.co/AYF9tIVXZs

核心是一套四层架构方案：原生外壳、系统 WebView、Node 后端、Rust 内核。

配合一份 75 项上线检查清单，逐条告诉你哪些细节会暴露「网页味」。

还附带 WebView 踩坑指南和内存优化参考，都是从 Raycast 实际产品中逆向总结的经验。

如果你正在做跨平台桌面应用，又不想让用户一眼看出是网页套壳，这个技能值得装上试试。

[FirstIntent @firstintentdev]

@GRT_Juggernaut @garrytan ontology

[FirstIntent @firstintentdev]

第一条路是企业agent，第二条路也许不存在，也许要像比特币一样被发明才会知道是什么东西

[土豆本豆 @Potatoloogs]

目前Agent的发展分成了两条路线。大部分讨论都集中在第一条上，但第二条可能更值得关注。

第一条：Harness式多Agent系统

多个agent共享上下文、共享目标、中心化调度，本质上是Workflow Engine加了个Ontology让它更灵活。

今天大部分多Agent系统的本质就是LLM Orchestration：一个大模型调度多个子角色完成复杂推理。这里面的Agent更像可调用的函数、带人格的工具、任务节点。

Prompt Engineering、Context Management、Task Routing、Tool Calling、Planning、Memory、Workflow。

本质仍属于软件工程问题。所以当年擅长编程的人都重获新生。

第二条：Protocol-Native Agent System

这条路的核心变化是：每个人拥有自己的Personal Agent，甚至是专属的无人公司。

这是一个极其巨大的变化。当Agent真正属于"个人"时，它的性质会发生根本变化：从task-scoped（任务级实例）变成identity-scoped（身份级实体）。

它有长期记忆、持续身份、偏好、资源、权限、历史、关系网络、利益边界，它代表"你"。

这时候Agent之间的协作没法再依赖Prompt、Workflow、Shared Context，只能依赖协议。因为当海量Agent独立存在时，它们之间必须解决：身份确认、权限边界、信任机制、委托关系、协商机制、激励机制、声誉系统、价值交换。

Agent之间的交互已经不是API Call，更像制度性交互。

AI世界的核心会从Prompt Engineering转向Protocol Engineering。

协议即组织

这个演变有三个阶段。

传统互联网里协议是数据通信：TCP/IP、HTTP、SMTP，发送和接收端约定说话的格式。

区块链里协议进化成状态计算：以太坊的本质是全网共同执行状态转换规则。

Agent Society阶段协议会继续升级，不仅定义通信和计算，还定义协调、权限、激励、身份、组织关系。协议开始承担"组织"的功能。

我的理解

现在读起来可能不太直观，因为第二条路线还没成为现实。

但回想三年前有人说"LLM提供基座能力、中间层提供原子能力、用户自己攒趁手的工具"。当时也觉得抽象，现在卡来就是vibe coding的日常。

第二条路线可能也是这样，过半年再看可能就能就get到了。

[FirstIntent @firstintentdev]

多 agent 真正有效的是按上下文切分

[yibie @yibie]

多 Agent 系统炒了一年，生产环境里真正活下来的只有三种模式。剩下的都在坟墓里。

这个结论不是我的。它来自三份今天同时浮出水面的证据——一份是 Cognition（Devin 背后的公司）工程负责人的内部复盘，一份是 Manning 作者 Micheal Lanham 的行业全景报告，还有一份，是 GitHub 上一个叫 metaswarm 的项目。

我把它们放在一起看，发现一件很有意思的事：它们说的竟然是同一句话。

---

## 三个信号，同一个判断

**信号一：metaswarm——18 个 Agent，127 个 PR，一个周末**

今天 HN 上最火的项目。一个人 + 18 个 AI agent + 一个周末 = 127 个 PR 推到生产。MIT 开源。看起来是多 Agent 协作的终极案例。

但如果你仔细看它的架构，你会发现一个被刻意隐藏的细节：**它的 18 个 Agent 不是在对等协作。它是 map-reduce-and-manage。**

一个管理者拆任务，17 个子 Agent 各干各的，管理者收结果、合并、push。Agent 之间不互相聊天、不互相审查、不互相投票。每一个子 Agent 面对的是自己那一小块独立的上下文。

它看起来像 swarm，但其实是流水线。

**信号二：Walden Yan 的内部复盘——「写入保持单线程」**

Walden Yan 是 Cognition 的工程负责人。他 10 个月前写了一篇《不要构建多 Agent 系统》，今天又写了一篇《多 Agent：什么真的有效》。

核心结论原话：「多 Agent 系统在今天最有效时，写入保持单线程，额外的 Agent 贡献智能而不是行动。」

他们试了三种模式：

1. **代码审查循环**——编码 Agent 写，审查 Agent 读。审查 Agent 拥有**完全干净的上下文**，不看编码过程，只看 diff。平均每个 PR 能发现 2 个 bug，58% 是严重的。关键发现：两个 Agent **不共享上下文**效果反而更好。因为上下文衰减——编码 Agent 工作几小时后积累了巨大的上下文窗口，注意力已经稀释了。干净的审查 Agent 反而更聪明。

2. **智能朋友**——主模型遇到棘手问题，调用一个更强（也更贵）的模型作为「朋友」。关键难点不是推理能力，是**沟通**：弱模型怎么知道自己到极限了？该传给强模型什么上下文？强模型怎么回话才能让弱模型真正理解？

3. **管理者-子 Agent**——一个管理 Devin 拆任务，子 Devin 各干各的，管理者综合。遇到的问题全是**沟通问题**：管理者默认过度规定（因为它缺乏代码库上下文）、子 Agent 不主动报告该让兄弟姐妹知道的信息、Agent 之间默认不传消息。

三种模式，同一条规则：**写操作的 Agent 只有一个。**

**信号三：Micheal Lanham 的行业全景——「多 Agent 失败是结构性的，不是提示词问题」**

Lanham 是 Manning《AI Agents in Action》的作者。他今天的文章标题就说明了一切：《Multi-Agent in Production in 2026: What Actually Survived》。

他把多 Agent 系统分成三种拓扑：

- **Agent-flow（流水线）**：顺序传递。A 做完交给 B，B 做完交给 C。这是生产环境里**存活率最高**的形态。
- **Agent-orchestration（编排）**：一个管理者调度多个执行者。map-reduce-and-manage。最实用的复杂任务形态。
- **Agent-collaboration（对等协作）**：Agent 之间互相通信、协商、投票。**几乎全死了。**

他的原话：「大多数看起来像『更多 Agent = 更聪明』的东西，其实只是相同信息的冗余重排列。」

三份报告，三个作者，没有互相引用。但结论完全一致。

---

## 为什么「对等协作」全死了？

答案藏在两个技术细节里。

**第一个，Walden 说的「操作携带隐式决策」。**

当一个 Agent 写代码时，它在做选择——用什么设计模式、怎么处理边界情况、变量命名风格、错误处理策略。这些选择不是显式的，是「隐式」的。

两个 Agent 同时写，就会对同一个问题做出互相冲突的隐式决策。最后合并的时候不是 merge conflict，是**设计哲学冲突**。这种冲突没有 diff 工具能自动解决。

**第二个，Lanham 说的「级联表面」。**

对等协作的失败不是线性的，是指数级的。Agent A 的误差传给 Agent B，B 放大后传给 C，C 再放大传给 A。三个循环下来，输出和输入的语义距离已经大到不可恢复。

这解释了为什么 2024 年所有那些「Agent 团队自动开发 App」的演示都停在了 demo 阶段。

---

## 那活下来的三种模式长什么样？

**模式一：流水线（Agent-flow）**

最简单的形态。A → B → C，一个接一个。像工厂流水线。

适用场景：需求明确、步骤可分、输出可验证。比如：需求分析 Agent → 代码生成 Agent → 测试生成 Agent → 代码审查 Agent。

活下来的原因：每一步的输入和输出是明确的、可检查的。出问题能定位到具体环节。

**模式二：编排（Orchestration = map-reduce-and-manage）**

一个强 Agent 做规划 + 拆解 + 综合，多个弱 Agent 并行执行子任务。

适用场景：复杂任务需要并行加速，但决策权必须集中。比如 metaswarm 的 18 个 Agent，比如 Devin 的 manager-worker。

活下来的原因：写入操作只有管理者一个。子 Agent 贡献的是「智能」（分析、生成、搜索），不是「决策」。

**模式三：生成-验证（Generator-Validator）**

一个 Agent 写，另一个 Agent 读 + 挑刺。写的不看读的过程，读的不看写的过程。干净的上下文。

适用场景：代码审查、安全检查、内容审核。Walden 说他们在生产环境已经跑了很久。

活下来的原因：验证 Agent 的上下文是干净的。没有历史包袱，不会被编码 Agent 的错误假设带偏。

---

## 一个反直觉的结论

看了这三份报告，我最大的感受不是「多 Agent 不行」，而是一个更微妙的东西——

**多 Agent 系统真正解决的问题不是「更聪明」，是「更便宜 + 更可靠」。**

用同样的钱，跑 5 个便宜模型的并行流水线，比跑 1 个贵模型做全流程，出活质量更稳定、容错率更高、速度更快。

这不是 AGI 的突破。这是系统设计的胜利。

Walden 在文章最后说的：「我们正在构建一个世界，智能被注入软件开发生命周期的每一个阶段——不是作为一群自主行动者，而是作为一个协调的系统，扩展人类的品味。」

注意这个词：「协调的系统」，不是「自主的行动者」。

---

## 所以，别再造 Agent Swarm 了

如果你现在准备做一个多 Agent 项目，问自己三个问题：

1. **写入操作能不能只有一个人？** 如果能，继续。如果不能，单 Agent 可能更好。
2. **Agent 之间传什么上下文？传多少？** 这不是提示词问题，这是架构问题。传多了淹没接收者，传少了接收者无法做正确决策。
3. **失败会怎么级联？** 如果 Agent A 错了，Agent B、C、D 会跟着错到什么程度？有没有断路器？

如果你对这三个问题没有清晰的答案，你就还没有准备好上生产。

多 Agent 的未来是真实的。但不是你想的那种未来。

不是一群 Agent 在聊天室里讨论怎么做。是一个指挥，多个执行者。是一种结构设计，不是魔法。

---

**参考来源：**
- Walden Yan (Cognition): [Multi-Agents: What's Actually Working](https://t.co/Pc1hk1M33u)
- Micheal Lanham: [Multi-Agent in Production in 2026: What Actually Survived](https://t.co/1VXEpxjDE4)
- metaswarm: [18 AI agents, 127 PRs to prod in a weekend](https://t.co/GAmTJPN0Pd)
- Anthropic: [anthropics/skills](https://t.co/sM8iiNTC8U) ⭐

[Julian Goldie SEO @JulianGoldieSEO]

https://t.co/BS0IApWM0e

[AYi @AYi_AInotes]

说实话，Garry Tan 这篇长帖，是我今年看到的最重要的 AI 文章，没有之一。

大多数人看完估计只会惊叹：“哇，这个读书工具好厉害。”

但他们其实并没看懂，这不仅仅是一个工具，说是一份 AI 时代个人能力的指数级放大说明书更合适一些。

先看那个最震撼的案例：
Book Mirror。

把一本 162 页的书扔进去，40 分钟后，产出 3 万字的深度脑页。

注意，这可不是普通的读书笔记，
而是要把作者的每一个观点，都精准映射到他自己的人生里——

他的家庭历史、YC 工作、治疗笔记、和几百个创始人的对话。

相当于这本书的作者专门花了两天时间，只和他一对一深聊，并且只聊和他最相关的那部分。

比 $300/小时的治疗师高效 50 倍以上，而且这已经远远超越普通 RAG。

普通 RAG 只能检索，

[FirstIntent @firstintentdev]

@lidangzzz 机会恰恰蕴藏在最难解决的场景里面

[FirstIntent @firstintentdev]

怎么出现在自媒体的上游

[Jaden思考日志 @Jaden_riku]

AI 时代，自媒体人最该盯的不是更多 AI 写作工具，而是这些“信号源网站”：

Reddit：真实痛点
Google Trends：搜索趋势
TikTok Creative Center：短视频趋势
Product Hunt：新工具/新产品
GitHub Trending：技术早期信号
Hacker News：硅谷讨论
Substack：深度观点
Meta Ad Library：竞品广告
AnswerThePublic：用户问题
Pinterest Predicts：审美趋势

内容生产不稀缺，发现需求才稀缺。

为了方便大家直接触达，我把网址列在了评论区
⬇️

[huangserva @servasyy_ai]

他凭什么拿到 每年 60 万美元的薪资？因为他能让 AI 直接处理数万亿级数据。
这场讲座本身非常值得看！

用 1 小时讲清楚：如何搭建能处理“万亿、万亿次浮点运算”的机器学习系统。

建议收藏起来，哪怕少刷一集 Netflix，看完都不亏。

这帖里有一个事实错误。讲者 Horace He 不是 Jane Street 员工，而是受邀来做技术讲座的嘉宾。

[FirstIntent @firstintentdev]

产品经理应该扔掉 axure 或 figma。开发在设计完工作流后也扔掉 IDE。

这个可能是未来的开发形态。 Dev 在搭建好 agent 开发工作流后，人人都是产品经理去提需求。

[凡人小北 @frxiaobei]

刚好今天下午跟团队开会，聊到了 Symphony。

过去这段时间团队手搓了一套系统，想解决一个很现实的问题：
别再让产品和技术被各自的工具链锁住了。

现阶段虽然 AI Coding 大家虽然玩的很溜，但认知上还未对齐，还在遵守老的规范，产品做需求，做完需求评审，评审完以后技术守着 codex、claude code 或者 cursor 这种本地工具，开发协作还是靠人肉对齐，整个过程其实很割裂，效率也不稳定。

这个平台做的事情很简单粗暴，要把这些能力收敛到同一套平台里，让 coding 从人驱动工具切换变成 Agent 任务驱动。

今天刚好讨论的一个关键点就是任务要用 Symphony 串起来。

什么意思？

就是以后团队里任何一个人，只要不颠覆大的设计目标，都可以直接提需求 → AI 自动拆解 → 自动构建 → 自动交付初版。

所有人要做的事情只剩两件，提需求、验证、兜底。

你可能会说，OpenAI、Authoropic 这些公司已经这么干了，但其实对于我们来说，现阶段可能刚刚好。

现状是开发到提测这个流程是没什么问题了，接下来我们打算把产品也收到这里边来，测试也尝试对接进来，看看到底能走到一哪一步。

[kabikabi @jakevin7]

最近开发 Slocal 过程中，UI真是太折磨我了！
找到了一个非常好用的UI Skill，分享给大家，里面收纳了非常多很强的设计相关的skill。

https://t.co/rxCv2Yk2QO

[FirstIntent @firstintentdev]

大脑太忙了

[AYi @AYi_AInotes]

holy shit， 兄弟们，这才是程序员的终极形态啊，太牛逼了😲😲😲

Beff刚刚转发的这个演示，直接给我看麻了，忍不住喊了好几声卧槽，把我家猫都吓一激灵🤣🤣🤣

Even Realities的G2智能眼镜出了Terminal Mode，
把一个完整的Claude终端，
直接浮在了你的眼球上🤯🤯🤯

你不用再坐下来，不用再开电脑，
不用再等笔记本加载。
在公园散步的时候，边走边让AI帮你写接口。
坐火车的时候，窗外的风景上飘着终端，AI在实时输出设计规范。
深夜走在街头，霓虹灯旁边就是正在生成的3D交互逻辑。

你说一句话，AI就自动适配眼镜的硬件限制，直接给你代码、逻辑、动画描述。真正做到了走到哪，写到哪。

Beff说的太对了，你可能不喜欢，
但这就是巅峰性能的样子。
它直接把开发环境从电脑里，搬进了你的眼睛里，把上下文切换成本干到了零，damn🤨🤨🤨

以后vibe coding再也不是梗了，
直接变成了真实的工作流。

以前你需要专门腾出时间进入coding状态，现在你任何碎片时间都能迭代产品。

等咖啡的两分钟，地铁上的半小时，散步放空的时候，全都是生产力。

对于solo founder来说，这就是核弹级的武器。

当然也有人吐槽，说这样再也没有真正的下班了，注意力边界会彻底消失。
但Beff那句“You may not like it”已经说透了，
老派的生活方式注定要被淘汰，
你喜欢不喜欢，历史的车轮都会碾过去。

这已经不是一个新功能了兄弟们，一个新物种诞生了！

一个可以边走边思考，边看世界边创造的后人类程序员诞生了！

而且我认为眼镜也只是过渡，
下一步，就是直接连到大脑🤯🤯🤯

[FirstIntent @firstintentdev]

Symphony 是 OpenAI 于 2026 年 4 月开源的 Agent 编排规范，GitHub 上线 2 周就达到 15K stars。

核心思路：把 Linear（任务管理系统）变成 Coding Agent 的控制面。

---

背景：遇到了什么问题

OpenAI 内部大规模使用 Codex 之后，工程师需要同时管理 3-5 个 Codex 会话——哪个会话在做什么、哪个卡住了、怎么推进——上下文切换成了新的瓶颈。他们意识到：自己实际上是在"微管理 AI 初级工程师"，这不能规模化。

---

解法：让 Agent 从任务列表里自己认领工作

不再由人打开会话、分配任务，而是：
- 每个 Linear open ticket = 一个 Agent workspace
- Symphony 持续监听任务看板，每个待处理任务都有 Agent 在跑
- Agent 完成后提 PR，附上功能演示视频
- 人只需要 review PR，不需要全程盯着 Agent

效果：部分团队的 PR 合并量在前 3 周提升了 500%。

---

三个关键特点

1. 工作流文档化（WORKFLOW.md）
原来工程师默默遵循的流程（建分支、提PR、改到CI通过），现在写成文件，Agent 遵照执行。流程从"在人脑里"变成"在代码仓库里"。

2. Agent 可以自己创建新任务
执行中发现了性能问题、重构机会，直接 file 新 ticket 等待排期。人来决定要不要做，Agent 负责发现。

3. 本质是一个 SPEC.md 文件
Symphony 的核心不是复杂的代码框架，而是一份规范文档，描述"对每个 open task，保证有 Agent 在运行"。OpenAI 鼓励各团队把这个 SPEC.md 扔给自己的 Agent，让它自己实现一个版本。

---

对研发团队的参考价值

如果用 Linear 管理开发项目的任务：
- 把 ticket 写成 AI 可理解的 spec（明确目标、边界、验收标准）
- 用 Symphony 思路让 Agent 自动认领、执行、提 PR
- 人的精力集中在 review 和决策，而不是监管 Agent

GitHub：https://t.co/HZP35zz9rU

[OpenAI Developers @OpenAIDevs]

📣 What if every open issue had a Codex agent?

That’s the idea behind Symphony, an open-source agent orchestrator for Codex that turns task trackers into always-on systems for agentic work, letting humans focus on review and direction.

[Joruno @wsl8297]

在 GitHub 上挖到一门很实用的开源课：Learn Harness Engineering，专门教你给 AI 编程助手搭一套更可靠的“工作台”。

它把 AI 协作拆成五个关键机制：指令、状态、验证、范围、会话，让每次任务都可追踪、可续接、可验证，不再靠运气出结果。

GitHub：https://t.co/G1kBghFqXg

官网：https://t.co/6OHbxJcWz6

课程结构很清晰：12 节理论 + 6 个实战项目，用同一个桌面应用贯穿推进，边做边演进。
从最基础的对比实验起步，逐步把整套工作环境搭起来；每个项目的产出，直接接到下一个项目继续用，越做越稳。

更贴心的是，它还提供可直接复用的模板文件：拷进自己的项目就能上手，不用完整学完，也能立刻提升 AI 的稳定性和可控性。

如果你已经在用 Claude Code 或 Codex 做真实开发，却总觉得 AI 时好时坏、难以复现，这门课很值得花时间看看。