nekocode @nekocode_cn关于这里，我的看法不一样 👀
在我看来 subagent 要解决的，还是「上下文」这个老难题。因为 llm 的上下文容量和注意力都是有限的，用不同的上下文来处理不同的任务是目前工程上的最优解。
而 subagent 在这里的核心价值就是上下文隔离，也是原 up 说到的，防止不同任务之间上下文互相污染。因为某段上下文对某个任务来说可能非常有用，但是对另一个任务来说可能就是噪音了。
你提到的类比成 thread/coroutine/worker，我感觉表象上确实是这样，但是核心要解决的问题可能不一样。
nekocode @nekocode_cn开源了其中一个我自己最常用的 harness 实践。
我习惯在每个项目里维护一份 FILETREE.md：完整文件树 + 每个文件由 AI 生成的一句话描述 + 用于感知变更的 hash。
本质上，这是为项目提前构建了一层文件维度的索引，对 agent 而言，是密度 / 性价比极高的上下文，特别是在中小型项目里，加了这么一段信息，对 agent 快速理解整个项目有非常大的帮助。
https://t.co/6MADl8tp2u
nekocode @nekocode_cn公司这周非常突然地裁了员，我们 team 砍掉了一半左右，留下来的人被分到了其他 team。
我算是侥幸留了下来，但被分到了一个不太 match 的团队。所谓「插班生往往是下一轮的炮灰」，我也说不准自己还能撑多久 😅
这让我想起之前听过的一个说法：「一家公司有多少人，不取决于它需要多少人，而取决于它能养得起多少人。」这个观点挺有意思，也很贴合经济上行期很多公司的行事逻辑。但在如今经济下行的大环境下，我感觉越来越多的公司开始认真思考一个问题，「维持正常运转，最少需要多少人」。
裁员、失业会是常态。每个打工人都需要警觉起来。
microstrong @Microstrongs@nekocode_cn @yihui_indie Agent 开发模式下，多人- Agent 协作确实是一个新的挑战。
多人在方案制定阶段是有明显好处的，但如果到开发阶段，直接 subagents 就好了。
plantegg @plantegg有了 AI 之后，飞书文档承受了从来没有过的压力：
1）新文档生成速度直线上升
2）读写比例达到新低，也就是架构估计得重构了
以前大家都知道一般读写比例是 95:5，现在估计接近 50:50 了
这些文档大家也没真的去看，在各个会议上，在 CEO CTO CXO 以及各级工程师之间一视同仁地互相糊弄
Yufan Sheng @syhily不知道是不是我的使用姿势不正确，推油大吹特吹的 CodeGraph 在我这使用效果相当一般。还不如 Agent 自己去 Grep。
nekocode @nekocode_cn一点心得，harness engineering 的本质是「熵减」。
而代码优于 prompt 约束，尽量把所有流程、约束，收敛到更稳定、有序的代码层去实现。
这也是 skills（agent 时代的 app）原生支持 scripts 的核心逻辑所在。
nekocode @nekocode_cn你如果在用 SDD，那我不建议你把 Spec 持久化。因为 Spec 会漂移！
代码在变，Spec 却不一定跟着更新。过时的 Spec 不是文档，是噪音，是幻觉的温床
真正的「唯一真相来源」应该只有一个：代码本身
又或许你更需要的是 Plan Mode，或者一个全局唯一的 Spec: ARCHITECTURE.md
nekocode @nekocode_cn一点心得，harness engineering 的本质是「熵减」。
而代码优于 prompt 约束，尽量把所有流程、约束，收敛到更稳定、有序的代码层去实现。
这也是 skills（agent 时代的 app）原生支持 scripts 的核心逻辑所在。
nekocode @nekocode_cnGUI IS BULLSHIT!
就算强如 Claude Opus 4.6，在 Vibe coding GUI 项目时（尤其是非 Web 栈），在稍微复杂的交互场景下，总容易会有 Bug 或细节问题，很容易让细节狂魔抓狂。
反观非 GUI 项目，Vibe coding 简直行云流水，身心愉悦。
看来文本喂出来的模型，终究是个半瞎 🤔
nekocode @nekocode_cn谁说 Agent Client Protocol 只能给 GUI 用 🤣
Team/Swarm 模式很可能是 Coding Agent 在 2026 年真正爆发的关键方向。可以预见，每个主流 Coding Agent 都会推出自己的 Team Mode —— 但一个更有意思的问题是：怎么让不同厂商、不同架构的 Coding Agent 组成一个异构 Team？
目前市面上已经有一些尝试，但各有局限：
1. Headless 模式：通过 Coding Agent CLI 的 Headless 模式来编排多个 Agent。问题在于，各家的 Headless 模式普遍是阉割版——功能覆盖不全，交互能力也大打折扣，远不如完整的 CLI 交互体验。
2. PTY 劫持：直接通过伪终端（PTY）接管 Coding Agent CLI 的输入输出。这种方式虽然理论上能获取完整能力，但信噪比极低——你需要从大量终端控制字符、ANSI 转义序列和格式化输出中解析出真正有用的信息，既脆弱又难以维护。
而 ACP（Agent Client Protocol）提供了一个更优雅的解法。 它在 CLI 交互之上抽象出一层统一的、结构化的协议层，让上层编排系统无需关心底层 Agent 的具体实现细节，就能以一致的方式与不同的 Coding Agent 进行通信和协作。
基于这个思路，我做了一个开源项目来验证这个想法 👇
https://t.co/Sl1nMKd7Yq
nekocode @nekocode_cn上下文工程，我常用的一个小技巧:
让 AI 把现状先写到一个 MD 文件里
git commit
Review & 修改 MD 文件
/clear
让 AI 基于 git diff（你对现状的修改意见）去解决问题
nekocode @nekocode_cn上下文工程，我常用的一个小技巧:
让 AI 把现状先写到一个 MD 文件里
git commit
Review & 修改 MD 文件
/clear
让 AI 基于 git diff（你对现状的修改意见）去解决问题
nekocode @nekocode_cnGit Worktree 绝对是驾驭 Coding Agent 最需要的功能之一：
快速 Fork 出多个隔离、干净的工作目录，让多个 / 不同的 Agent 并行探索不同方案，最后再 Merge 回主分支 —— 有冲突？也交给 Agent 处理就行。
这绝对是 Coding Agent 的并发放大器！
现在不少 GUI / IDE 已经支持 Worktree 管理，但如果你是 CLI 原教旨主义者，强烈推荐 agent-worktree，在保留 Coding Agent CLI 100% 原生能力的同时，补齐了 Worktree 管理能力。
nekocode @nekocode_cn介绍下 agent-worktree 的功能：SNAP 模式 ⚡
搭配 Claude Code 使用，任务完成、退出 CLI 时自动 merge 回主干。
用过 Conductor 但更喜欢 CLI 的朋友，你应该会很喜欢它。
Lyric🌀 @lyricwai效果如图，它自己去 https://t.co/DkYrGAJL2n 生成了 PDF，没问我要 APIKey，也没有把 APIKey 暴露到 prompt
Michael Anti @mranti我有一个小小的意见：我怎么觉得现在skills炫耀的功能，基本上我很快就可以用Claude Code手搓一个Python程序完成了，而且更稳定、更快、随时可调整订制。当然Skills把和AI的互动简化了，不过我觉得它增加的不确定性、控制力弱、延迟等问题，超越了它带来的好处。
lcomplete @xlcomplete有趣，太有趣了。
这个思路太棒了，让 Agent 访问数据库比访问文件系统更高效。
一看到这条推文，我的脑回路立刻就被激活，思路一下子打开了。
1、很早之前就被 Agent 从数据库查数据的能力给震惊过，Agent 只要能连对应的数据库，不需要提供表名等信息就能找到你想要的东西，也能轻松搞定数据统计和分析。
2、我在实现 huntly 的知识库对话功能时想过两个方案：markdown 和 mcp，却从来没想过让 agent 直接去数据库里查。
要让「知识库对话」更顺畅一些，只需要再结合时下流行的 skills，写一个 markdown，大致让 AI 知道 huntly 数据库是干嘛用的，以及一些关键数据要怎么查询就可以了。
换个角度，整个事情变得如此简单。
用我最近常说的句式来收尾，huntly 的含金量又变高了。😋
宝玉 @dotey“你们应该多用 Bash。”
过去几周，Anthropic 的 Thariq 和几十家做通用智能体的公司开了电话会议。邮件助手、客服机器人、日程管理——各种产品形态都有。聊完一圈，他发现自己反复在说同一句话。
Bash？那不是程序员用的命令行工具吗，和这些产品有什么关系？
先看一个具体场景。
假设你有一个邮件 Agent，你问它：“这周我在打车上花了多少钱？”
传统做法是这样的：Agent 调用 API 拉取邮件，可能一次性取回 100 封，然后让模型从里面找 Uber、Lyft 的收据，加总金额。
问题在于 100 封邮件塞进上下文，模型要同时记住这些内容，从中筛选、计算。这对大语言模型来说并不轻松。容易漏，容易错，而且你没法验证它到底看了哪些邮件。
这就是典型的模型舒适区问题：数据量不算大到需要专门写程序处理，但又超出了模型一次性硬算的能力范围。夹在中间，很尴尬。
Thariq 的方案是：给 Agent 一个 Bash 工具，让它把中间结果存成文件。
听起来很简单，但背后的逻辑很有意思。
传统的工具调用是这样的流程：
工具 → 模型处理 → 输出结果
所有中间状态都在模型的“脑子”里，你看不见，也没法检查。
换成 Bash 之后，流程变了：
工具 → 存文件 → 搜索/过滤 → 模型处理 → 输出结果
模型可以先把 100 封邮件存到一个文件里，然后用 grep 搜“Uber”，再 grep“Lyft”，分别统计。每一步都有迹可查，最后加总的时候，它还能回头检查自己的中间结果。
这带来三个能力升级：
可复现。同样的命令再跑一遍，结果一样。你可以调试，可以排查问题。
可验证。模型不是凭“记忆”给你答案，而是基于实际文件里的数据。你信不过的话，自己也能打开文件看一眼。
可组合。一个命令的输出可以作为下一个命令的输入，管道一接，复杂任务就能拆成简单步骤。
Bash 让 Agent 从“脑算”变成了“打草稿”。草稿可以留痕，可以检查，可以改。这对需要准确性的任务来说太重要了。
邮件搜索只是最直观的例子。Bash 的能力边界其实很宽。
链式 API 调用是个常见需求。比如“把这周我发过邮件的联系人都找出来”，这需要先拉邮件列表，提取收件人，去重，再逐个查询联系人详情。一连串操作用 Tool calls 来做，调用次数多，中间状态难管理。用 Bash 脚本串起来，逻辑清晰得多。
视频和文件处理也是 Bash 的强项。ffmpeg 这个命令行工具，模型用起来得心应手。找视频里某个片段、裁剪、转码，一行命令搞定。
还有定时任务。在 Agent 运行的容器里，用 cronjob 或 at 命令就能创建定时执行的任务。用户说“每天早上 8 点给我发一份新闻摘要”，Agent 可以自己设好闹钟。
这些场景有个共同点：都需要多步骤操作，都需要保存中间状态，都超出了单次工具调用的能力范围。
但 Bash 是把双刃剑。
能执行命令意味着能做很多事，也意味着能做很多危险的事。rm -rf 一不小心就能删光整个目录。如果 Agent 被恶意提示词攻击，后果可能很严重。
Anthropic 显然考虑到了这一点。他们在 Claude Agent SDK 里做了一套权限系统，包括 Bash 命令解析器和分级权限控制。哪些命令可以直接执行，哪些需要用户确认，哪些完全禁止，都可以配置。
我用 Claude Code 的体会是，这套权限系统确实降低了心理负担。它会在执行敏感操作前询问你，而不是闷头就干。但安全护栏不是万能药。权限系统本身也可能有漏洞，Bash 解析器也可能被绕过。
安全护栏是必需品，但不能因此就觉得万事大吉。
强调 Bash 的好处，也得说清楚它的边界。
如果任务足够简单，别用。“今天天气怎么样”这种一次性查询，直接调 API 返回结果就行，没必要存文件再处理。杀鸡用牛刀反而更慢。
如果环境是 Serverless 的，用不了。很多云函数运行时没有可持久化的文件系统，Bash 的“存中间结果”优势就没了。
如果对安全要求极高，谨慎使用。命令注入的风险无法百分之百消除，金融、医疗这类场景可能更适合用白名单式的专用工具，而非通用的 Bash。
工具的选择取决于场景，而不是工具本身的强弱。Bash 很强，但不是所有场合都该用。
回过头看，Thariq 这条建议的真正价值不是“Bash 很强”这个结论，而是背后的思维方式：
让 Agent 的思考过程“落地”到可检查的中间产物。
传统的 Agent 设计把所有东西都塞进模型的上下文，一锤子买卖。Bash 提供了另一种路径：把复杂任务拆开，每一步都留下痕迹，可以验证，可以回溯。
想想看，这和人类处理复杂问题的方式多像。我们做复杂计算时会列竖式，写长文章时会先拟提纲，处理大量信息时会做笔记。不是因为脑子记不住，而是因为落到纸上更可靠、更容易检查。
Agent 也一样。不是说模型处理不了，而是有中间产物的流程更值得信任。我自己用 Agent 辅助写作，所有中间产物都会存成文件：网络检索资料、提纲、不同版本的草稿、画图的提示词。这些存下来后续就可以灵活组合。
Bash 不只是程序员的工具，更是让 Agent 具备可验证、可复现、可审计能力的关键一环。
Yumin @YuminAIAnthropic这帮人是有病吧
他们发明了plugin, agents, skills
但这不都是一堆markdown文件吗
为什么还区分那么多？
无非都是prompt
ok，有些prompt可以被重复使用
但你也不致于发明这么多概念啊
你就老老实实的说
这个是做ui的prompt
这个是做code review的prompt
这个是做web search的prompt ， 但你可以同时开多个进程来跑这个prompt
我他妈还寻思这都是什么高科技呢
天天装神弄鬼，也不学点好
宝玉 @dotey我个人不喜欢 Spec-Driven Development，有点像瀑布模型写系统设计文档，理论上看起来很牛，但是并不好操作，另外容易想的太多。
我比较推崇小版本迭代，不需要写详细的 spec，几句简单的 prompt 就可以开始生成，每次写一个可以跑起来的版本，然后一点点迭代，每次迭代完都是可以运行的版本
另外大多数时候，Claude Code 的 Plan Mode 就足够好用了，根据你当前想实现的，会写一个 plan 文档，可以反复沟通确认。
Benson Sun @BensonTWNFTX 倒了三年了。
撇開 SBF 做的那些事不談，純粹從產品角度來看，FTX 很多功能放到現在依然能打，甚至領先現在多數交易所。
子帳號系統到現在沒有任何一家做到類似體驗。FTX 的子帳號是原生帳號架構，不是那種層層疊疊、權限綁手綁腳的設計。開一個子帳號就像開一個全新帳戶，乾淨俐落。
美股代幣FTX 上輪週期就在做了。這輪才開始有交易所把這當賣點來宣傳，晚了一整個週期。
Quant Zone 更是一絕。不用寫程式就能建立自動化策略，我以前做套利都直接開 Quant Zone 跑，省下大量開發時間。
其他產品還包括指數合約、槓桿代幣，以及當時全網唯一的每小時結算、無cap 的資金費率，和 RFQ 的 OTC desk。
FTX 的產品設計確實超前了這個行業一整個週期。三年過去了，如果 SBF 沒作惡，如果 FTX 還在 ，我相信還會引領更多 CEX 的創新，真的可惜了。
