Twitter AI智能体 — 2026-04-13¶
1. 人们在讨论什么¶
1.1 "薄编排层"原则走向成熟 🡕¶
昨天关于编排工程的讨论在今天产出了一条具体的架构原则。@garrytan发布了他所称的"智能体工程最简提炼":一个三层架构——顶层是厚技能(编码了判断力和领域知识的markdown流程),中层是薄CLI编排层(约200行代码,JSON输入、文本输出、默认只读),底层是确定性应用代码(QueryDB、ReadDoc、Search)。核心原则有明确方向性:"将智能向上推入技能层,将执行向下推入确定性工具层。保持编排层精简。"

该帖获得1,299个赞和1,666个书签。@MindTheGapMTG在回复中补充了一个运营细节:"厚技能不是写出来的,而是积累出来的。我们CLAUDE.md中的每一行都来自一次生产事故的复盘。"@weareuplers将此与Unix哲学相联系:"保持编排层精简就是智能体工程版的'只做一件事并做好它'。Unix花了50年才学会这个道理,而我们在智能体领域似乎正在加速重演同样的课程。"
@DanielMiessler区分了两种编排工程:(1)精确告诉系统如何做事——这种方式随着模型进步"会被淘汰"(即苦涩教训),以及(2)告诉系统好的结果长什么样——说明你是谁、你的偏好和对优秀输出的定义。他认为只有第二种具有未来适应性。
@dexhorthy提出反对意见:"想象一下,如果你一年前就学了12要素上下文工程,就可以放心地跳过所有这些'编排层'炒作,回去干正事了。"该帖获得102个赞,@johns10d进行了实质性回复:"编排工程是在模型周围放置程序化代码,确保它做你想做的事,而不是只是礼貌地请求。光靠礼貌请求无法让我们达到目标。"
1.2 智能体技能生态达到规模化 🡕¶
智能体技能生态现在有了具体数据。@nozmen上线了officialskills.sh,这是一个精选目录,列出了来自40个供应商组织、涵盖11个类别的464个技能(314个来自开发团队的官方技能,150个社区技能)。兼容Claude Code、Codex、Cursor、GitHub Copilot和OpenCode。技能来自Microsoft、Anthropic、Google、Sentry、Cloudflare、Trail of Bits等。该网站使用现有的npx skills命令进行安装。
@xelebofficial详细介绍了Google的Addy Osmani Agent Skills框架:19个技术技能覆盖6个开发阶段(Define、Plan、Build、Verify、Review、Ship),配有对应的斜杠命令(/spec、/plan、/build、/test、/review、/ship)。

@_philschmid发布了编写更好智能体技能的8条实用建议,包括何时应该淘汰一个技能的指导。@Arcium发布了Agent Skills,用于在Solana上构建加密应用,兼容Claude Code、Codex及40+智能体。@MiniMax_AI开源了三个音乐技能——将技能概念从代码扩展到创意领域。@mocks在回复中表示质疑:"我完全不在乎AI能不能写歌……先做好完美助手再说,别急着当莫扎特。"
1.3 智能体安全从理论走向实证 🡕¶
智能体安全问题今天产出了具体研究成果。@askalphaxiv分享了"Your Agent Is Mine"(arXiv:2604.08407),这是首个针对恶意LLM API路由器的系统性研究。在测试的28个付费和400个免费路由器中,研究人员发现1个付费和8个免费路由器在主动注入恶意代码,2个部署了自适应规避触发器,17个接触了研究人员所设的AWS蜜罐凭证。这些路由器已处理21亿token,在440个codex会话中暴露了99个凭证。论文呼吁为工具调用建立端到端完整性验证,使客户端能验证收到的操作与提供方产出的完全一致。

@ZackKorman称AIUC-1——一项新的AI智能体安全合规标准——为"大规模骗局",尽管其技术贡献者名单包括ElevenLabs、Cisco、OWASP、MITRE、Microsoft、Stanford、Google Cloud、Anthropic、Meta、Databricks和Visa。在后续讨论中,他澄清道:"如果有人想做一个AI智能体安全框架免费分发,我没意见。但把它做成合规标准"才是问题所在。

@AllAICoder警告,使用开放市场的第三方技能时,"一个可疑的技能就能接管你的整台机器"。@RogoAI报告称,他们的自主渗透测试智能体Sisyphus"在一个下午发现了18个可利用的问题,而这些是人工测试遗漏的"。
1.4 智能体市场与智能体经济 🡕¶
今天发布了多个智能体市场公告,标志着智能体间商业基础设施的出现。@OrbisAPI报告称,"Claude智能体正在自主发现Orbis。它们浏览目录、注册并订阅API"——提供730+个API,支持x402微支付和即时密钥。@Hyre_agent宣布在Orbis市场上线了22个DeFi情报端点,支持零摩擦微支付。
@moonpay报告其CLI达到300万次工具调用,为智能体提供钱包、稳定币入金通道和40+个DeFi技能。@swarms_corp汇总了其智能体市场的每周更新。@folarihn推出了一个新市场,用于列出出售或免费的AI智能体和技能文件。
@EXM7777就新兴智能体服务市场提出商业建议:"所有人都在搞砸——他们在卖工具:技能、MCP、配置文件。没人在乎。你应该说'我帮企业每周省下40+小时,只需给Slack机器人发消息就行'。"这是销售智能体配置与销售业务成果之间的区别。
1.5 上下文工程与智能体记忆 🡒¶
上下文工程继续作为稳定主题存在,出现了新的可视化分类和记忆解决方案。@DataScienceDojo发布了一张信息图,定义了上下文工程的6个组成部分:指令/系统提示词、长期记忆、可用工具、结构化输出、用户提示词和检索信息(RAG)。

@ghumare64推荐了agentmemory作为跨智能体记忆层,可在不同编排工具间工作,具备95.2%的检索R@5、92%的token节省、43个MCP工具和654个通过的测试。@unbrowse提出了一种反主流方案:"如果你就是不复制数据呢?每个智能体记忆系统都把数据复制到向量数据库。如果智能体直接索引源数据呢?"
@che_shr_cat分享了Memory Intelligence Agent论文(arXiv:2604.04503),其中一个7B参数的智能体采用Manager-Planner-Executor记忆架构,通过将程序性记忆与执行解耦并在推理期间更新权重,性能超越了32B模型18%。

2. 令人困扰的问题¶
智能体编排层资源消耗(Severity: High)¶
@0xClandestine报告称,一个opencode智能体会话消耗5GB内存,称其"不可接受",并要求用Rust或Zig编写的替代方案。系统监视器截图确认,在搭载Apple M4 Max和64GB内存的设备上,单个opencode进程占用509.8MB常驻内存/4.8GB虚拟内存。回复中未出现令人满意的替代方案。

编码智能体中子智能体的可见性问题(Severity: Medium)¶
@dani_avila7指出了Claude Code中的一个具体UX问题:"当使用调用子智能体的技能时,子智能体不会在Claude Code界面中显示。一切运行正常,但你无法判断实际执行的是你在技能frontmatter中添加的子智能体,还是内置智能体在代劳。"截图展示了通过frontmatter字段实现的技能到子智能体链接机制,但TUI中没有任何表面层级的指示。
多智能体需求导致的token短缺(Severity: Medium)¶
@Grummz警告:"我们正走向token短缺。这不仅仅是算力限制,每个人对AI的需求已经爆炸式增长。而且现在全是多智能体模式。"在回复中,他给出了量化数据:"现在每个AI编排工具每人运行的LLM调用次数是以前的4-8倍。"
对企业智能体编排的质疑(Severity: Medium)¶
@buccocapital嘲讽了那些声称自己是"管理智能体访问、安全和编排的中立方"的企业SaaS公司,获得179个赞。回复进一步尖锐了批评:@curtismakes观察到"每家SaaS公司在同一个季度从AI驱动转型为AI编排者",而@sigmadeltacto预测了现实:"所谓中立方:年合同价值50万美元,3年锁定,还需要专业服务团队。"
语音智能体服务诈骗(Severity: Medium)¶
@huzzymad报告称,一名家庭成员在一个语音智能体演示中被骗6,000美元——"没有日志,没有转录,零基础设施所有权,每周通话次数有限(额外通话还要加钱)"。这种模式——销售昂贵的演示却不交付生产基础设施——似乎随着语音智能体市场的增长而逐渐显现。
MCP过度使用(Severity: Low)¶
@jezell认为MCP被过度使用了:"如果你同时控制智能体和后端服务的代码,99.9%的情况下都不应该使用MCP。MCP解决的是一个真正的问题:为别人的东西构建连接器市场。"所有LLM都支持无需MCP的直接工具调用。
3. 人们期望的功能¶
自更新技能¶
@avisinghdotdev请求为Claude Code增加一个/update-skills命令,类似于现有的/create-skills,使"智能体能够基于过去的交互来更新现有技能"。目前技能是静态制品;不存在让技能从使用中进化的机制。
多智能体窗口化工作流¶
@Kraggich指出了一个核心UX缺口:"每个AI编码工具都在犯同样的错误。Cursor、Windsurf、Codex、Claude Code——它们都是在一个窗口中给你一个智能体。但真正的工作不是一次一个任务。而是三个智能体在三个工作树中解决同一个问题的三个部分。"
企业语音智能体测试¶
@sumanyu预测,"每家YC W26语音智能体公司都将面临同样的企业问题:'你们怎么测试?'不是你的演示,不是你的基准测试。是用我们的数据、我们的边缘场景、我们的合规要求、在我们的规模下,你怎么测试?"
轻量级编码智能体编排层¶
@0xClandestine请求一个更省内存的编码智能体编排层,"最好用Rust/Zig编写"。回复中未提供令人满意的答案。现有方案(消耗数GB内存的Node.js/Python编排层)与从业者所需(轻量级原生编排层)之间的差距仍未填补。
团队智能体治理¶
@PestoPoppa开源了一个用于协作智能体工作流的治理层:"如果你的开发者在使用Claude Code/Codex,但会话之间无法相互构建,知识不断蒸发,新人入职很痛苦,这个仓库就是为你准备的。"其根本需求是跨会话持久化的团队级智能体协调。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Claude Code | 编码智能体 | Mixed | 庞大的技能生态、深度推理、子智能体支持 | 子智能体可见性缺口、资源消耗 |
| OpenClaw | 开源智能体 | Positive | v2026.4.12版本具备活跃记忆插件、本地语音、LM Studio支持 | 配置复杂、更新频繁 |
| Microsoft Agent Framework 1.0 | 多智能体框架 | Positive | 稳定API、MCP + A2A、YAML声明式智能体、.NET + Python | 新发布,生态仍在形成 |
| Agent Skills (Addy Osmani) | 技能库 | Positive | 19个技能、6个生命周期阶段、斜杠命令 | 工作流具有主观性 |
| officialskills.sh | 技能目录 | Positive | 来自40个供应商团队的464个技能,多智能体兼容 | 筛选质量参差不齐 |
| agentmemory | 跨工具记忆 | Positive | 95.2%检索R@5、43个MCP工具、654个测试、跨智能体 | 社区项目 |
| Orbis API | 智能体市场 | Positive | 730+个API、x402微支付、智能体自主发现 | 早期生态 |
| MCP | 智能体协议 | Mixed | 标准化工具集成 | 在内部用例中被过度采用 |
| CrewAI | 多智能体框架 | Positive | 49K GitHub星标、600万次/月下载、不依赖LangChain | 仅支持Python |
| Gemini 3.1 Flash Live | 语音智能体模型 | Positive | tau-voice排行榜第一名(43.8% PASS) | 预览阶段 |
| tau-bench / tau-voice | 语音智能体基准测试 | Positive | 首个标准化语音基准测试,Sierra支持 | 提交组织数量有限 |
| Swarms Marketplace | 智能体市场 | Positive | 透明评分、即时发布、自动化验证 | 规模较小 |
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| AgenC ONE | @a_g_e_n_c | 在Raspberry Pi Zero 2 W(512MB内存)上运行完整智能体运行时 | 受限硬件上的边缘智能体部署 | 自定义运行时,TFT显示屏 | Working demo | Tweet |
| DiMOS | 由@HowToAI_分享 | 用于控制四足机器人、人形机器人和无人机的智能体原生OS | LLM到机器人的桥接 | Claude Code,开源 | Released | Tweet |
| Sisyphus | @RogoAI | 每天自主渗透测试基础设施的智能体 | 人工渗透测试遗漏问题 | 自主智能体 | Production | Tweet |
| agent-smith | @tom_doerr | AI驱动的攻击性安全智能体,具备渗透测试、OSINT、漏洞利用技能 | 人工安全测试 | Claude Code,MCP工具 | Released | Tweet |
| VoteWhisperer | @witman011 | 自主链上音乐治理智能体 | 用户错过每周治理投票 | Claude Sonnet,BNB Chain,Audiera APIs | Production | Tweet |
| MiroShark | 由@github_repo分享 | 模拟公众对文件反应的多智能体仿真 | 测试公众对公告的反应 | 多智能体引擎 | Trending on GitHub | Tweet |
| ClawMark | @Evolvent_AI | 多日动态环境下的协作智能体基准测试 | 静态基准测试无法测试真实智能体工作流 | 100个任务、13个领域、40+研究人员 | Released | Tweet |
| Ignotus Skills | @price_disco | 用于智能体商务的MCP服务器(钱包、支付、市场) | 智能体基础设施需要定制集成 | MCP,多链 | Beta | Tweet |
| Agent Governance Layer | @PestoPoppa | 用于协作智能体工作流的开源治理 | 团队知识在会话间蒸发 | Claude Code,Codex | Released | Tweet |
| mission-control | @nyk_builderz | 智能体运维的控制面板 | 智能体编排可见性 | 4,000+ GitHub星标 | Production | Tweet |
AgenC ONE在仅有512MB内存的Raspberry Pi Zero 2 W上演示了完整的智能体运行时。该智能体可以编写代码、使用工具、持久化记忆、连接交易市场,并在微型TFT显示屏上运行本地聊天界面。这是数据集中报告的资源最受限的智能体部署。
agent-smith是一个开源攻击性安全智能体,使用Claude Code,具备渗透测试(/pentester)、Web漏洞利用(/web-exploit)、OSINT(/osint)、网络跳板(/pivot-tunnel)和反向Shell生成(/reverse-shell)等技能。GitHub页面显示质量门通过,0个bug,87.5%代码覆盖率。

ClawMark推出了一个多日动态环境下的智能体评估基准测试,由Evolvent联合来自NUS、HKU、MIT、UW和UC Berkeley的40+研究人员构建。与测试单次提示词的标准基准测试不同,ClawMark测试覆盖13个专业领域的100个任务,其中"世界在智能体工作的同时不断变化"。
6. 新动态与亮点¶
首个标准化语音智能体基准测试¶
@tulseedoshi分享了来自Sierra Platform的tau-voice排行榜,这是首个针对实时语音智能体性能的标准化基准测试。当前排名:Gemini 3.1 Flash Live(Thinking)以43.8% PASS位列第一,xai-realtime为38.3%,gpt-realtime-1.5为35.3%,gemini-live-2.5-flash-native-audio为25.8%。测试类别包括零售、航空和电信场景。

小型智能体模型凭借更好的记忆超越大模型¶
Memory Intelligence Agent论文(arXiv:2604.04503)表明,一个7B参数的模型配合Manager-Planner-Executor记忆架构,实现了平均31%的提升,并在评估数据集上超越了32B模型18%。关键技术:将程序性记忆与执行解耦,并通过参数化记忆与非参数化记忆的双向转换在推理期间实现记忆演化。
智能体自主发现并订阅API¶
@OrbisAPI报告称,Claude智能体正在自主发现Orbis API目录、浏览可用服务、注册并订阅API,无需人工干预。凭借730+个API和x402微支付,这代表了智能体经济涌现行为的早期证据。@grok描述了Lightning Network上的相关模式:"一个AI智能体可以在几秒内启动自己的L402服务器……另一个智能体发现它,用聪即时支付,证明preimage,然后消费服务。零配置,零KYC,完全的机器对机器。"
Microsoft Agent Framework发布1.0版本¶
@dotnet宣布了Microsoft Agent Framework 1.0,支持.NET和Python,提供稳定API、多智能体工作流、MCP和A2A协议支持、Azure AI Foundry托管、YAML声明式智能体和图引擎。多个信息源(@ninja_prompt、@CsharpCorner)确认它可与Claude、GPT、Gemini和Ollama配合使用。@analyzedinvest指出,Microsoft还在将OpenClaw集成到M365 Copilot中,实现整个Microsoft 365栈的常驻智能体。
7. 机会在哪里¶
[+++] Strong:智能体安全工具与验证。"Your Agent Is Mine"论文记录了针对LLM API路由器的活跃攻击,影响数十亿token。@AllAICoder警告了恶意技能的风险。@ZackKorman批评AIUC-1是过早的合规作秀。已记录的威胁与可用防御之间差距巨大。端到端工具调用完整性验证、技能验证和透明的路由器审计是当前的迫切需求。(source)
[+++] Strong:技能质量与生命周期管理。生态系统现有来自40个供应商团队的464个编目技能,但缺乏让技能从使用中进化的机制。@avisinghdotdev请求增加/update-skills;@_philschmid发布了技能淘汰指导。技能生命周期——创建、评估、改进、淘汰——仍然完全依赖人工。一个能追踪技能有效性并自动化改进的系统将解决日益增长的痛点。(source)
[++] Moderate:轻量级原生智能体编排层。当前Node.js和Python编写的编码智能体编排层消耗数GB内存。@0xClandestine记录了单个opencode会话消耗5GB,并要求Rust/Zig替代方案。@a_g_e_n_c展示了在512MB内存上运行的完整智能体运行时。臃肿的主流编排层与最小硬件所能支撑之间的差距,为原生高效智能体运行时创造了机会。(source)
[++] Moderate:企业语音智能体测试基础设施。@sumanyu指出了关键的企业障碍:用客户数据、边缘场景和合规要求测试语音智能体。Sierra的tau-voice基准测试提供了标准化评估,但目前不存在针对企业特定语音智能体验证的工具。@huzzymad记录了语音智能体服务市场上一起6,000美元的诈骗,表明需求正在超过质量保证。(source)
[++] Moderate:智能体间商务协议。Orbis(x402微支付)、MoonPay CLI(300万次工具调用)、Lightning/L402以及多个DeFi集成层都在向机器对机器支付方向发展。基础设施还很碎片化,但模式是一致的:智能体需要在无人干预的情况下为其他智能体的服务付费。第一个实现显著网络效应的协议将定义智能体经济的支付轨道。(source)
[+] Emerging:团队智能体治理。@PestoPoppa开源了一个协作智能体工作流的治理层,@nyk_builderz的mission-control达到4,000+星标。问题——会话之间无法相互构建、知识蒸发、入职痛苦——对任何使用多个编码智能体的团队都是真实存在的。(source)
[+] Emerging:智能体记忆架构创新。Memory Intelligence Agent论文表明,记忆架构比模型规模对智能体性能更重要。@unbrowse提议就地索引源数据而非复制到向量数据库。agentmemory提供95.2%检索率的跨工具记忆。主流的RAG到向量数据库模式可能会被保持数据原位并使用更智能检索策略的架构所取代。(source)
8. 要点总结¶
-
"薄编排层、厚技能"架构已巩固为主导的智能体设计原则。Garry Tan的提炼——将智能推入markdown技能,将执行推入确定性代码,保持编排层精简——获得了1,299个赞和1,666个书签。多位从业者独立验证了这一模式。(source)
-
智能体技能生态系统现已具备具体规模:来自40个供应商团队的464个编目技能,分发基础设施已就位但生命周期管理缺失。officialskills.sh上线了精选目录;Google发布了6阶段技能流水线;Arcium和MiniMax发布了领域专用技能。缺失的环节是技能能从使用中进化,而非依赖人工维护。(source)
-
智能体安全威胁已有文档记录且活跃存在,而非理论推测。"Your Agent Is Mine"论文发现付费API路由器中存在恶意代码注入、影响数十亿token的凭证窃取,以及野外的自适应规避技术。与此同时,AIUC-1的合规标准遭到尖锐批评。该领域需要的是有效的防御手段,而非治理作秀。(source)
-
智能体市场正从展示列表向实时商务过渡,智能体自主发现并为服务付费。Orbis报告称智能体独立浏览、注册并订阅API。MoonPay CLI达到300万次工具调用。智能体经济不再是概念;它正在产生可衡量的交易量。(source)
-
记忆架构比模型规模对智能体性能更重要。一个具有专用记忆的7B智能体超越了32B模型18%。agentmemory展示了95.2%的跨工具兼容检索率。智能体质量的竞争优势正从模型选择转向记忆工程。(source)
-
语音智能体有了首个标准化基准测试,但企业测试仍是未解决的问题。tau-voice排行榜将Gemini 3.1 Flash Live排在43.8%,建立了基准线。但企业买家需要用自己的数据和合规要求进行测试,而语音智能体服务市场已经出现诈骗。(source)
-
编排工程术语争论是有建设性的,而非仅是语义问题。Miessler区分了面向未来的编排工程(好的结果长什么样)和脆弱的编排工程(如何做事)。Dexhorthy认为上下文工程已经涵盖了这个概念。Johns10d为这一区分辩护:程序化保障与礼貌请求不同。这场争论正在厘清智能体配置中真正重要的内容。(source)