三省六部Agent架构，是制度创新还是工程表演？_服务软件

1. 龙虾之后，为什么说「主动式智能」才是Agent的终极形态？

2. Google 最新的白皮书，很值得收藏！《Introduction to Agents》，这个白皮书几乎可以看作是对“智能体时代”正式宣言。它系统地定义一种新型软件范式——让模型能自主思考、决策和执行。AI 正在从“预测”走向“行动”。1. 从预测式AI到行动式AI过去的AI是“被动的”：模型接收输入、生成输出，一问一答。但这篇文档开篇就指出，我们正在经历一次范式转变——从“预测AI（Predictive AI）”到“自主智能体（Autonomous Agents）”。智能体的关键区别在于：它不再等人指令，而是能围绕目标自我规划、行动、再评估。Google 把这类系统定义为一个闭环结构：LLM + 工具 + 编排层 + 部署环境。LLM提供推理，工具执行动作，编排层控制整个“思考—行动—观察”的循环，而部署让智能体能长期运行和被复用。2. 智能体的工作循环：Think–Act–Observe文档用一个非常清晰的五步模型解释智能体的工作方式：1. 获取任务（Get the mission）2. 扫描场景（Scan the scene）3. 思考计划（Think it through）4. 执行动作（Take action）5. 观察反馈（Observe & iterate）这一循环让智能体具备了真正的“任务感”。举个例子：用户问“我的订单在哪？”，智能体不会立刻回答，而是分解出“查订单→查物流→整合结果→回复”的完整路径。我特别喜欢它强调的那句话：智能体的本质，是上下文窗口的策展人（curator of context window）。——它不断组织、更新、过滤信息，让模型始终聚焦在当前任务最关键的上下文上。3. 智能体的分级：从单脑到群体这份白皮书提出了一个五层级的智能体体系：Level 0：仅推理模型（纯LLM）Level 1：能调用外部工具的“连接型问题解决者”Level 2：具备策略规划与上下文工程能力的“战略型智能体”Level 3：多智能体协作系统（类似团队协作）Level 4：自我演化系统（能创造新工具或子智能体）这一分级体系几乎可以当作企业部署智能体架构的路线图——从简单的调用API，到让智能体学会分工合作，最后走向能自我改进的“学习型组织”。4. 三大核心组件：脑、手与神经系统Google 把智能体拆成三个核心部分：1. Model（脑）：推理与决策中心，负责思考。2. Tools（手）：执行动作的能力，比如RAG、API、代码执行。3. Orchestration Layer（神经系统）：调度逻辑、记忆与策略，实现“Think–Act–Observe”循环。有一个关键点：他们认为模型并不是越大越好，而是要根据任务选择最优组合——复杂任务用强模型（如Gemini Pro），高频简单任务则用轻模型（如Gemini Flash）。这种模型分层调度的思路对未来Agent架构很关键。5. Agent Ops：智能体的运维哲学文档中提出了一个新概念——Agent Ops。它相当于 DevOps 在智能体时代的延伸。因为智能体行为具有不确定性，传统的“单元测试=预期输出”已经失效。Agent Ops 的目标是通过指标驱动、日志追踪、模型评审和用户反馈闭环，让系统在不确定中保持可靠。一个新的职位或部门来了？Agent Ops6. 安全与治理：从单Agent到Agent Fleet当智能体数量增多，问题就从“怎么造一个Agent”变成“如何管理一群Agent”。Google 提出的解决思路是建立控制面板（Control Plane），统一管理身份、权限和通信协议（MCP/A2A），避免Agent Spraw（智能体泛滥失控）。有意思的是，文中引入了“Agent作为新型主体（principal）”的概念，认为Agent不只是代码，而是一种能独立被认证、被授信的行动体。7. 学习与自演化：Agent Gym 的想象力最后几章讨论了“Agent如何自我进化”。Google 提出了一个概念叫 Agent Gym，类似模拟环境，用来让智能体在离线条件下训练、演练、红队测试、吸收人类反馈，从而“成长”。这个暂时用不上，估计大公司比较有资源搞。——这两个新的点，之前没深刻理解：1. Agent = 新的软件范式。过去我们以为“智能体”只是“会用工具的模型”，但Google用这份文档明确告诉大家——Agent是一种新的软件范式。它不是应用AI，而是用AI重新定义应用。2. Agent的核心不在“思考”，而在编排（orchestration）。未来的开发者更像导演而不是程序员——我们要设计场景、挑演员、布置镜头，让智能体自然演出目标行为。#ai创造营##科技#

3. #千问发布会# 从接入的app就可以看出来，AI agent目前还是只能大厂来做，否则根本没有app会给你这么大的权限。阿里巴巴的技术能力说没问题的，但是产品能力不大行，钉钉内嵌的AI agent就有不少不如人意的地方，看未来如何演进吧。现在来说，无论发布会上吹的多牛逼，用户拿到的产品的可用性都要大打折扣。 #老张聊科技# http://t.cn/AXGt4d6H

4. 高低得试试这个，突然火🔥得不行的开源项目，The Agency（agency-agents）：144个专业AI智能体，你的从不下班的AI全明星团队！支持一键部署到 OpenClaw龙虾，Claude Code，Antigravity， Cursor 等工具中。1. 高度专业化这不是"act as a developer"这种通用提示词，而是真正的职业人设。比如：1）Frontend Developer — React/Vue/Angular专家，不只是写代码，还关心Web Vitals优化和性能2）Backend Architect — API设计、数据库架构、微服务设计的深度思考3）AI Engineer — ML模型部署、AI集成、数据管道的完整理解4）Security Engineer — 威胁建模、代码审计、安全架构5）Rapid Prototyper — 快速MVP开发，不追求完美，只追求快速迭代每个Agent都有：1）独特的性格和工作风格2）清晰的使命和工作流程3）具体的交付物（代码、文档、指标）成功衡量标准例子：Code Reviewer 的自我介绍是"我不仅仅审计代码——我默认每次能找到3-5个问题，并且所有发现都需要视觉证明。"2. 分类清晰，覆盖全面144个Agent分布在12个事业部：1）工程部（50个Agent）Frontend Developer、Backend Architect、Mobile App BuilderDevOps Automator、Security Engineer、Database OptimizerAI Engineer、Embedded Firmware Engineer、SRE甚至还有WeChat Mini Program Developer（针对中国市场）2）设计部（8个Agent）UI Designer、UX Researcher、Brand GuardianWhimsy Injector（"注入一点调皮"的角色，负责交互动画和细节惊喜）3）营销部（30+个Agent）Growth Hacker、Content Creator、Twitter Engager中国本地化专家：Xiaohongshu Specialist、Douyin Strategist、WeChat Official Account Manager、Zhihu Strategist4）销售部（9个Agent）Outbound Strategist、Discovery Coach、Deal Strategist、Sales Engineer5）产品部（5个Agent）Product Manager、Sprint Prioritizer、Trend Researcher6）游戏开发部（20+个Agent）Game Designer、Level Designer、Technical ArtistUnity Architect、Unreal Systems Engineer、Godot Gameplay Scripter7）测试部（8个Agent）Reality Checker、Evidence Collector、Performance Benchmarker、Accessibility Auditor还有支持部、项目管理部、空间计算部、专项部等。3. 一键部署到主流AI工具支持Claude Code（官方推荐）、GitHub Copilot、Google Gemini（Antigravity）、Cursor、Aider、Windsurf、OpenClaw、Qwen Code等。项目：github.com/msitarzewski/agency-agents#HOW I AI# #程序员#

5. 《走近科学》——多Agent不是万能药，从玄学走向科学，来自Google和MIT的研究

6. 回复@微微清凉的风:帮转//@微微清凉的风:宝玉老师，感谢你推动AI内容传播你3/5转的Edict「三省六部×AI」，核心创意来自我的开源项目（GitHub @wanikua，2/22发布）。Edict 2/23创建（晚21小时），15个设计决策完全一致。我项目40 star，他3000+ star，大家都以为是他原创证据: github.com/cft0808/edict/issues/55 如能帮忙澄清，万分感谢

7. #DeepSeek新模型为何被夸爆#DeepSeek新模型被广泛认可，核心在于其实现了性能与成本的双重突破。其V3模型凭借MLA架构、MoE架构和混合精度框架三大技术，在降低资源消耗的同时实现了性能跃升。训练成本仅为OpenAI同类模型的1%，却能在主流榜单跻身开源模型榜首，与顶级闭源模型性能相当。这种高效设计打破了大模型高成本的固有认知，让更多开发者能以低门槛获取强大AI能力。文字变图像等多模态能力的实现，标志着AI从单一文本处理迈向多信息维度融合的新阶段，能更全面地理解和生成不同形态的内容。这种技术思路必然会被其他大模型借鉴，因为轻量化与多模态融合已成为行业趋势，前者解决资源瓶颈，后者拓展应用边界，二者结合能显著提升模型的实用价值，这也是AI技术落地的关键方向。#科技#

8. 转：David Singleton，前 Stripe CTO 最近有个观点很炸裂：当我们所有人都觉得 AI 时代最危险的是 manager，因为不需要中间层了嘛，agent 直接干了。结果他现在优先招那些以前当过 manager 但现在想回来写代码的人。原因是他认为 manager 天然擅长拆解任务、协调资源、知道什么时候该推一把什么时候该放手，他认为这才是驾驭 coding agent 最核心的能力。----我觉得说的没有错的，不过这里重点不是当没当过 Manager，而是同时有架构能力和管理能力，能拆分任务，能管理 Agent。说实话，很多 manager 技术不咋地，就会向上管理和 PUA，但管 Agent 重要的不是向上管理，也不是 PUA，而是“定义问题”和“知人善用”。

9. 大模型Agent的核心还是prompt？

10. 【别搞错了，生产级AI Agent的核心根本不是AI，而是分布式系统】快速导读：大多数人以为构建Agent就是“Prompt+工具”的循环，这是一种危险的误解。一旦涉及真实用户、高并发和容错，Agent就从一个AI问题，变成了经典的分布式系统工程问题。这解释了为什么大量Agent项目最终都只是个玩具。 --- 很多人觉得，构建AI Agent无非就是把Prompt和工具扔进一个循环里。这个假设很合理，但它根本就不是生产环境的架构。你的Agent一旦需要知道自己在跟谁说话、需要保持状态、处理并发请求、执行敏感操作，以及在工具调用失败后幸存下来——它就不再是一个“LLM+工具”的简单组合，而蜕变成了一个不折不扣的分布式系统。构建Agent本身是简单部分，市面上有无数框架帮你搞定。真正的难点在于“运行时”——那个包裹着Agent、让它能在真实世界里可靠工作的系统。这才是所谓的“智能体软件工程（Agentic Software Engineering）”。构建Agent是AI工程，但在生产中运行它是软件工程。这套工程体系由六根支柱撑起：持久性、隔离性、治理、状态、扩展性和可组合性。每一个都指向经典的分布式系统难题，比如数据隔离失败就是数据泄露，而服务过载则意味着你继承了所有第三方API的速率限制和延迟。这解释了为什么那么多Agent项目最终都像个漂亮的玩具，却无法成为可靠的产品。AI行业还没有完全吸取过去几十年我们在构建可靠分布式系统中学到的教训。最终，能把这套软件工程的纪律内化到团队血液里的，会交付出伟大的产品。而那些继续把Agent当作脚本对待的，会继续与成功失之交臂。 --- 简评：一针见血。AI圈的热潮让很多人忘了，再聪明的“大脑”也需要一个强壮的“身体”才能在现实世界里行动。这篇文章把焦点从算法和模型，拉回到了决定产品生死的工程纪律上。当你的Agent需要审批、回滚、保证用户数据隔离时，你面对的就不是一个AI问题，而是对你软件工程成熟度的拷问。 --- ref: x.com/ashpreetbedi/status/2028176285575594465 #AI创造营##人工智能#

11. 快手1.6万字长文《快手万人组织 AI 研发范式跃迁之路：从平台化、数字化、精益化到智能化》，推荐阅读文章介绍了快手研发范式的三阶段演进路径，以及快手技术团队对 AI 赋能组织提效的思考。三阶段演进路径：1. 平台化、数字化、精益化（2023-2024 年）：2. 建设一站式研发平台，并标准化需求和工程流程，工具渗透率>95%，流程自动化>94%3. 通过建立效能模型，识别交付瓶颈，提升需求交付效率，人均需求吞吐量提升 41.57%4. 智能化 1.0（2024 年 6 月 -2025 年 6 月）：聚焦用 AI 提升个人开发效率- 建设并推广 AI 编码 / 测试 /CR 等能力，AI 代码生成率超过 30%- 但发现矛盾——个人主观编码效率提升显著，但组织需求交付效率却基本不变5. 智能化 2.0（2025 年 7 月以后）：聚焦用 AI 提升组织整体效能- 找到了 AI 研发范式升级路线：L1 AI 辅助（Copilot）→ L2 AI 协同（Agent）→ L3 AI 自主（Agentic）- 探索出了支撑路线达成的系统性实践：AI x 效能实践、AI x 研发平台、AI x 效能度量关键洞察与经验：1. AI 研发提效陷阱：用 AI 开发工具 ≠ 个人提效 ≠ 组织提效2. 本质问题：如何将个人提效传导到组织提效原文：mp.weixin.qq.com/s/Ejxpxn_MrJ1PDf-K38MpEg#HOW I AI# #程序员#

12. #IT那些事儿# 为什么当前所有 Coding Agent 在长期任务中都会退化中山大学和阿里联合发布的这篇《SWE-CI：Evaluating Agent Capabilitiesin Maintaining Codebases via Continuous Integration》论文提出来一种新的衡量标准：衡量一个AI牛不牛，不看它能不能一秒钟写一个页面或一秒钟修好 Bug，而要看它在长达半年的项目演进中，能否不把代码库搞砸。他们从 GitHub 上筛选了 68 个存活 3 年以上、≥ 500 星的开源仓库，从中构建了 100 个任务，每个任务对应该仓库真实的历史演化片段。让AI在这个漫长的历史长河中，一轮一轮地去理解新需求，修改代码。论文提出了一个叫 EvoScore 的评估指标，这个指标本质上是对"每轮代码质量变化"的未来加权均值——越靠后的迭代权重越高，越看重长期稳定性，所以它更看重代码的长期可维护性。结果显示，绝大多数当前被吹上天的 AI 大模型，它们在连续几十轮的开发迭代中，能保持完全不破坏历史功能的概率不到百分之二十五。哪怕是目前霸榜的顶级模型，零回归率也才勉强过半。马工对此评价说：SWE-CI 的 Zero-Regression Rate（零回归率）惩罚的是每一轮迭代中的回归——哪怕 Agent 下一轮就修好了，依然扣分。这等于奖励畏手畏脚，惩罚大胆重构。一个敢做大改动然后收拾干净的 Agent，反而比一个每次只改一行的 Agent 得分低。所以这个 benchmark 测的不是“可维护性”，而是“胆小程度”。他们这个试验里，最大的漏洞是，把正常的迭代内的测试失败视作一种缺陷，这个在我们实践经验中，是完全不可接受的。打个比喻来说，我现在用语音输入法输入文字，那这个过程中肯定有很多错别字，但是语音输入法会在发送之前把这些错别字都改掉。而他这篇论文会把这个过程中的错别字视为缺陷，加以统计并排名。这就是 Methodology 问题了。我又看了下论文，SWE-CI 设计了两个 Agent：- 架构师 Agent- 程序员 Agent其中，程序员 Agent 被设计成无法执行测试（原文里有一个 no_execution 约束明确禁止 Programmer Agent 主动跑 pytest）。每轮迭代结束后，是外部 CI 系统统一跑测试。所以大致流程类似于：架构师 Agent 根据需求制定增量需求文档 → 程序员 Agent 修改代码 → CI 跑单元测试 → 架构师 Agent 分析错误根因、调整需求文档 → 如此循环。零回归率只是一个事后统计指标，并不参与 Agent 的决策循环，也没有影响到程序员 Agent 的行为，所以不存在“奖励畏手畏脚，惩罚大胆重构”的机制。这个机制真正的问题可能在于，架构师 Agent 定需求，程序员 Agent 盲写代码并没有得到反馈（而真实开发者的修复过程通常是信息收集、代码搜索、候选修复与单元测试的时序交织，在这个过程中不断得到反馈、学习并进步），架构师 Agent 去看 CI 测试结果并调整需求，这个过程是不自然的——架构师看的是测试报告，程序员看的是需求文档，两者之间隔了一层翻译，信息在每次传递中都在损失。如果换成真实人类团队在这个机制下工作半年，大概率也会崩。SWE-CI 的设计可以把这个 no_execution 约束去掉，让程序员 Agent 可以主动执行 pytest，它在本地看到测试结果后，再决定下一步怎么改代码。只有当它自己认为满意了，才“交卷”给外部 CI 系统。也就是给程序员 Agent 一张草稿纸，这样可能会稍微好一点。有意思的是，现实中成熟的 coding agent 都是这么做的——Claude Code 等都会在本地跑测试、看报错、自我修正。SWE-CI 反而把这个最核心的反馈循环人为切断了，然后去测"没有草稿纸的写作能力"，这是它设计上最值得商榷的地方。不过如果真的做类似的长期的实验，可能会发生三件事：1）编码成功率上升，但不会暴涨。2）模型会更大胆，但 bug 类型更复杂。3）长期仍然会出现系统性退化。这个“系统性退化”在软件工程语境里其实就是技术债自动积累。因为长期来看，Agents 跟人在屎山代码中的行为一样，模型会逐渐忘记系统的隐含规则，上下文漂移 + 约束遗忘，和人一样一样的。原因是另一个更深的问题：大模型对隐式系统约束的建模能力很弱。隐式约束在计算上到底是什么？隐式约束 ≈ 一个分布在代码库、历史演化、测试、文档、人类习惯中的“稀疏、非显式、不可完全观测的约束集合”大模型只能拟合和优化局部似然，但无法稳定保持“全局约束一致性”，说白了就是误差将不可逆积累。即使引入多 Agent 也不解决根本问题——SWE-CI 的双 Agent 设计本身就是一个例子：架构师和程序员之间的每一次需求翻译，都是一次信息损耗，约束在传递中不断被稀释。这意味着，SWE-CI 测出来的那个“系统性退化”，不是 benchmark 设计缺陷带来的假象，而是真实存在的能力天花板——只是论文自己还没有把这个更深的原因讲清楚。

13. n8n要凉了？Agent Skills实测对比，谁才是AI自动化之王！

14. 《智能体设计模式》第六章「规划模式」完成翻译了，目前已翻译章节：00 - 前言部分网页链接01 - 第一章：提示链模式网页链接02 - 第二章：路由模式：网页链接03 - 第三章：并行模式网页链接04 - 第四章：反思模式网页链接05 - 第五章：工具使用模式网页链接06 - 第六章：规划模式网页链接规划模式让智能体具备前瞻性思维能力，能够将复杂任务拆解为更小且可管理的步骤，并制定实现预期结果的策略。通过规划能力，智能体不再只是对眼前输入作出反应，而是能够自主规划从初始状态到目标状态的完整路径。这里为大家梳理几个关键要点：1. 核心理念：从被动响应到主动规划规划模式的核心在于建立「理解目标 → 制定计划 → 执行步骤 → 灵活调整」的智能流程，让智能体具备战略性、目标导向的执行能力。- 传统模式的局限：基础智能体只能对眼前输入作出反应，缺乏处理复杂多步骤任务的能力，无法将高层次目标拆解为可执行的子任务。- 规划模式的价值：智能体能够接收高层次目标并自主拆解为有序的执行步骤，在遇到阻碍时灵活调整路线，从而有效处理包含多个步骤和相互依赖的复杂任务。2. 规划的关键特征规划模式通过以下特征实现智能化的任务执行：- 目标驱动：接收高层次的目标声明（做什么）而非具体指令（如何做」，由智能体自主决定实现路径。- 即时生成：计划不是预先存在的，而是根据当前状况和目标要求即时生成的。- 灵活应变：初步计划只是出发点，智能体能够接纳新信息并在遇到阻碍时动态调整策略。- 结构化分解：将复杂目标拆解为一系列更小、可执行的步骤或子目标，按逻辑顺序处理依赖关系。3. 典型应用场景规划模式在四大领域展现出核心价值：- 流程自动化：编排复杂工作流，如新员工入职流程，包括创建账户、分配培训、部门协调等有序子任务。- 机器人与自主导航：进行状态空间遍历，生成从起始状态到目标状态的最优路径，同时遵守环境约束。- 结构化信息整合：生成研究报告等复杂输出，规划包含信息收集、数据归纳、内容结构化、迭代打磨等阶段。- 多步骤问题解决：制定并对系统化流程进行诊断、实施解决方案，并在必要时升级处理。4. 实现框架与特点- CrewAI：通过定义明确的智能体角色和任务，支持先规划后执行的工作流，适合结构化的多步骤任务。- Google 深度研究：利用多步骤动态迭代流程，把用户提示拆解为研究计划，循环执行搜索与分析，生成带引用的结构化报告。- OpenAI 深度研究接口：提供编程化控制能力，支持 MCP 协议连接私有知识库，展示完整的中间步骤（推理、搜索、代码执行）。5. 使用时机与权衡当任务复杂度超出单一操作范围时，应当使用规划模式，但需要权衡灵活性与可预测性：- 适用场景：任务需要多个相互依赖的步骤才能完成；「如何做」的方案需要探索而非已经明确；需要自动化处理复杂的工作流程；需要生成全面、综合的结果。- 权衡考量：当问题的解决方法已经清楚且可重复时，固定流程比动态规划更有效；规划增加灵活性的同时也引入了不确定性；需要在自主性和可预测性之间找到平衡。- 核心价值：将智能体从简单的被动响应者提升为战略性、目标导向的执行者，能够管理复杂流程并产出全面综合的结果。项目：github.com/ginobefun/agentic-design-patterns-cn/blob/main12-Chapter-06-Planning.md#人工智能##程序员#

15. ai agent的架构好像都差不多啊?有啥比较特别的吗？

16. 推荐吕鹏（@甩甩鸟哥很严肃）开源的 Agmente 项目，让你可以从 iOS 手机上操作 Coding Agent Coding Agent。 OpenClaw 让我们看到了很多从手机指挥 Agent 的有趣场景，通过 Agmente 你可以在手机上跟 Gemini CLI、Claude Code、Qwen 等 AI 编程 Agent 对话，实时查看它们的工具调用和执行结果。吕鹏是 VS Code 团队的工程经理，主导了将 Copilot Coding Agent 和 GitHub Copilot CLI 集成到 VS Code 的工作，可以说他是最了解编辑器如何与 AI Agent 对接这件事的人之一。Agmente 最特别的地方在于它实现了 ACP（Agent Client Protocol，智能体客户端协议）——一个正在快速崛起的开放标准。ACP 要解决什么问题？现在 AI 编程 Agent 越来越多（Claude Code、Gemini CLI、Codex CLI……），编辑器/IDE 也很多（VS Code、Zed、JetBrains、Neovim……）。如果没有统一标准，每个编辑器想接入每个 Agent 都要单独写一套集成代码，反过来每个 Agent 想支持每个编辑器也一样。这就是经典的 M×N 问题。ACP 就是来解决这个问题的。它的角色类似于当年的 LSP（Language Server Protocol）——LSP 让任何编辑器都能接入任何语言的智能提示，ACP 则让任何编辑器都能接入任何 AI 编程 Agent。Agent 实现一次 ACP，就能在所有支持 ACP 的客户端上运行；客户端实现一次 ACP，就能接入整个 Agent 生态。从这个项目也反映出 AI Agent 发展中几个值得注意的趋势：1）Agent 正在脱离桌面束缚。以前编程 Agent 只能在 IDE 或终端里跑，Agmente 让你在手机上就能监控和交互。想象一下：你让 Claude Code 在远程服务器上干活，然后出门遛弯时在手机上查看进度、审批工具调用——这就是 Agmente 支持的场景。它通过 WebSocket 连接远程 Agent，还支持 Cloudflare Tunnel 做安全访问。2）标准协议正在改变游戏规则。就像 MCP 让 Agent 能统一访问各种工具和数据源一样，ACP 让 Agent 能统一接入各种客户端界面。一个 Agent 写一次 ACP 适配，就能同时在 VS Code、Zed、JetBrains、甚至手机上被使用，这大大降低了 Agent 生态的碎片化。3）从“人用编辑器”到“人监督 Agent”的范式转变。 Agmente 的交互设计很能说明问题——它重点展示的不是代码编辑界面，而是对话历史、工具调用和执行结果。这暗示了一种新的开发模式：开发者的角色从写代码变成下达指令、审核 Agent 的行为。项目地址：github.com/rebornix/agmente 网页链接

17. AI Agent 的工作原理和架构是什么？

18. 看看这篇论文"Where LLM Agents Fail and How They Can Learn From Failures" 对我们构建Agents有什么可以借鉴的↓一、Agent 设计1. Agent 应显式模块化为四大核心环节：- Memory（记忆）：跨步检索过去状态、关键实体、任务目标。- Reflection（反思）：判断上一步是否有效、目标是否达成。- Planning（规划）：生成下一步策略，考虑约束与目标。- Action（执行）：把规划转化为具体操作（API、点击、文本输出等）。2. 系统级模块要独立定义- System 模块单独追踪环境层问题，如 API 报错、超步长、网络错误。- 避免模型把这些外部失败“误归因”为自身逻辑错误。3. 每一步应有完整的四模块流水线每个 step 输出 <memory>、<reflection>、<plan>、<action> 四段内容。这让后续错误追踪、纠错具备结构化基础。4. 模块化输出格式化用明确标签 ...，确保后续调试能准确分区分析。对 Reflection、Plan、Action 模块统一采用自然语言模板输出。二、错误理解与防护层5. 错误不是孤立的，而是系统的绝大多数失败并非某一步的局部问题，而是“早期错误的放大效应”。6. Error Propagation（错误传播）是核心敌人一次错误记忆或误判，会导致后续所有步骤都偏离正确轨迹。所以设计 Agent 时，应重点强化 early-stage robustness。7. 每层的错误类型- Memory：记忆失败、虚构记忆、过度简化。- Reflection：进度误判、结果误读、错误归因。- Planning：忽略约束、不可能行动、低效计划。- Action：格式错误、参数错误、计划-行动不一致。- System：API、环境、步数上限、模型限制。8. “根因错误（Root Cause Error）”是比“错误点”更重要的概念根因定义：若修正此处错误，则任务能成功。其他错误可能是“衍生”或“掩盖”错误。9. 错误识别应遵循最早原则找到第一个导致结果不可逆的步骤，而不是最后失败时的那步。10. 错误标注应以模块为单位每一模块都单独判定错误类型，保持因果可追踪。三、Agent 自调试与学习机制11. AgentDebug 的三阶段循环非常值得模仿（1）细粒度错误映射（Fine-grained Analysis）（2）关键错误检测（Critical Error Detection）（3）迭代反馈执行（Iterative Feedback Rollout）12. Fine-grained Analysis 阶段可由 LLM 直接完成使用错误定义表（taxonomy definition）自动匹配模块输出，判断是否符合特定错误模式。13. Critical Error Detection 阶段要引入“反事实测试”模拟性地修改一个步骤，若任务成功，则说明该步是根因。可用 binary search 或最早匹配法来确定。14. 反馈生成要具备可操作性（actionable feedback）Feedback 不是总结，而是对下一步执行的“修改建议”或“策略指令”。15. Agent 应能在下一轮 roll-out 中读取上一次反馈相当于“带记忆的 retry”，让每次失败成为学习信号。16. Re-rollout 不必从头开始从根因错误所在的步骤重新执行，节省算力，提高修复效率。17. AgentDebug 的本质是“以 LLM 驱动的调试层”它可作为任何 LLM Agent 框架（如 ReAct、AutoGen）的外挂组件。18. Iteration 控制设置最大调试轮数（如 3–5 次），防止死循环。每次迭代记录失败原因与修复建议。19. 反馈结构标准化使用结构化 JSON 输出包含：{ "critical_step": x, "critical_module": "planning", "error_type": "constraint_ignorance", "correction_guidance": "考虑任务约束条件重新制定计划"}20. 建立自成长记忆（Self-Learning Memory）记录每次任务失败的根因 → 在新任务中预防重复错误。类似“调试经验库（Debug Memory）”。四、数据与评估层（构建 AgentEval）21. 构建类似 AgentErrorBench 的内部测试集自己收集失败轨迹，手动标注错误类型和模块。用于回归测试与Agent鲁棒性评估。22. 聚焦三个代表性任务环境ALFWorld（具身交互）、GAIA（信息检索与推理）、WebShop（结构化交易场景）。分别对应不同 Agent 能力维度：感知、工具调用、交互执行。23. 评估指标要分层Step Accuracy：能否找到正确错误步骤。Step+Module Accuracy：能否同时识别模块。All Correct：步骤 + 模块 + 错误类型三者全对。24. 强调“检测准确率”和“任务恢复率”双指标检测正确 ≠ 任务成功；关键是能否利用检测结果指导恢复。25. 设计错误可视化工具使用 Sankey 或 heatmap 显示错误传播路径。可快速定位在哪些阶段最易出错。五、实践实现与架构优化技巧26. Prompt 层要分模块定义Memory、Reflection、Planning、Action 各有独立 prompt 模板。Prompt 中明确上下文依赖（Memory → Reflection → Planning → Action）。27. Reflection 模块应包含明确问句“是否完成任务？”、“上一步有效吗？”、“需要调整策略吗？”保证反思不是复述，而是真实的进度监控。28. 引入“Consistency Checker”在 Planning 与 Action 之间插入一致性验证器（plan–action alignment check）。29. 强化外部记忆的可控性限制记忆检索范围、使用关键片段索引，减少 false recall。30. 监控任务长度与中途崩溃对 step limit exhaustion 进行提前检测与主动调整。31. 测试小模型的鲁棒性时可配合 AgentDebug实验表明，小模型在有调试反馈时性能提升幅度更大。32. Debug 可与 Self-Refine、Tree-of-Thought 互补ToT 负责拓宽思考空间，AgentDebug 负责收敛错误与修复。33. 设计“学习率型调试”每次迭代调整反思深度或思维链长度，类似于 meta-learning。六、总体启发：让 Agent “学会失败”34. 失败不是终点，而是数据每一次失败都能产出一条训练样本：(错误类型 → 改进策略)。35. Agent 的进化逻辑从“执行任务”到“理解失败”再到“自我修正”，这一步是让 Agent 从工具变成认知体的关键。36. 未来方向构建“Debug Memory + Root Cause Feedback + Iterative Rollout”三位一体架构。让 Agent 不仅能反思，还能真正“debug 自己的反思”。如果你后续打算设计一个具备自调试能力的 Agent 框架，可以直接基于本论文提炼出一个五层结构原型：> Memory → Reflection → Planning → Action → Debug Layer（AgentDebug）其中 Debug Layer 执行 “错误识别 → 根因检测 → 修复反馈 → Re-rollout”。论文：www.researchgate.net/publication/396048725_Where_LLM_Agents_Fail_and_How_They_can_Learn_From_Failures#人工智能##ai创造营#

19. 在线开发智能代理系统遇到上下文管理难题？推荐看看 muratcankoylan 的开源项目「Agent Skills for Context Engineering」，这是一个面向生产级 AI 代理系统的全面技能库。它提供了完整的上下文工程方案，涵盖基础理解、架构设计、多代理协作、工具开发、评估优化等多维度技能，帮助你科学管理语言模型的上下文窗，实现最高效的上下文利用和智能决策。主要亮点：- 深入讲解上下文衰减、压缩和优化，避免模型“迷失中间”；- 支持多代理架构设计，含监督者模式、图谱记忆、沙盒环境等；- 提供完善的评估框架，支持LLM作为裁判进行性能对比和偏差缓解；- 包含项目开发全流程指导，从概念设计到流水线部署；- 独家认知架构技能，形式化建模代理心智状态，实现理性推理与解释；- 跨平台、通用原则，适配Claude Code、Cursor等主流代理平台。GitHub：github.com/muratcankoylan/Agent-Skills-for-Context-Engineering无论你是搭建单一代理还是多智能体系统，这套技能库都能助你构建、优化和调试高效智能体，推荐 AI 开发者和研究者深入学习！#AI创造营##人工智能#

20. 3天赚1200刀？纯聊天就能捏出个能搞钱的 AI Agent！【教程】

21. OpenClaw狂揽16万star，是时候聊聊Agent Tools的AB面了

22. AI Agent 很火，但 Agent Infra 准备好了吗？

23. Deep Agents：LangChain开源的Agent框架，开箱即用的LLM应用方案。核心思想：给你一个开箱即用的Agent，需要定制再加工。Deep Agents基于LangGraph构建，内置了单Agent应用的标配能力：任务规划、文件系统访问、Shell执行、子Agent委托、自动上下文管理。会话长了自动总结，大输出存文件，子Agent有隔离的上下文窗口。启动简单，支持任何能调工具的LLM（OpenAI、Claude、开源模型都行）。需要时加工具、换模型、调提示词。支持MCP。对比其他框架：1.LangGraph：底层编排框架，基于图和状态机。完全可控，支持流式、持久化、断点恢复。缺点是学习曲线陡，小任务过度设计。2. CrewAI：多Agent协作框架，建在LangChain和LangGraph之上。提供Agent、Task、Crew等高级抽象，快速定义多Agent分工。优点是上手快，缺点是多Agent固定模式，非标准行为定制困难。3. AutoGen（Microsoft）：事件驱动，支持conversation-based Agent交互和group chat。v0.4引入强可观测性和异步模型。适合多Agent对话，不适合需要持久化和复杂状态的应用。4. Deep Agents的位置：单Agent框架，高于简单的ReAct（思维链+工具调用），低于多Agent系统。填补了这个缝隙：需要快速上手，但又要求工业级的规划、文件访问、子Agent能力。技术特点：1. Deep Agents采用trust-the-LLM模型——Agent可以做工具允许的任何事，安全边界由工具和沙箱保证。这套思路来自Claude Code，也就是LangChain在把Claude Code的经验系统化。2. 上下文管理做得细致：会话自动总结、大输出转文件、子Agent隔离上下文窗口。处理长期运行任务（爬虫、研究、报告生成）时能显著降低token消耗。应用场景1. 快速原型或一次性脚本 → Deep Agents足够2. 复杂单Agent任务（爬虫、研究、代码生成） → Deep Agents很合适3. 多Agent协作 → CrewAI更顺手4. 需要完全自定义Agent行为 → LangGraph完全控制5. 对话式多Agent互动 → AutoGen更原生项目：github.com/langchain-ai/deepagents#HOW I AI# #程序员#

24. 论文 Fundamentals of Building Autonomous LLM Agents，系统性地梳理 “如何构建一个真正具备自主性的 LLM 智能体”，也就是从「语言模型」走向「智能体」（而不仅仅是增强的聊天机器人／工具调用系统）。论文提出希望解答以下几个研究问题（RQs）：（1）设计空间（Design space）：核心子系统（感知／推理／记忆／执行）有哪些可选方案？如何系统化组织？（2）子系统整合（Integration）：在现实软件环境（比如 GUI、web 任务）中，这些子系统如何闭环协作？（3）推理效能（Reasoning efficacy）：不同推理策略（如 Chain-of-Thought、Tree-of-Thought、并行规划等）对任务成功率、效率、成本有什么影响？（4）记忆影响（Memory impact）：短期／长期记忆机制（例如 RAG、上下文管理）怎样提升模型在长时程任务或大上下文任务中的表现？（5）失败模式与缓解（Failures & mitigation）：代理在哪些方面容易失败（如幻觉、GUI误定位、重复循环、工具误用）？有哪些缓解技术？（6）评估与泛化（Evaluation & generalization）：有哪些基准／指标适用于评估此类代理？代理能在多任务、多界面条件下泛化吗？★ 核心架构论文将一个具备自主能力的 LLM 智能体拆解为以下四大模块：1. 感知（Perception）系统2. 推理／规划（Reasoning／Planning）系统3. 记忆（Memory）系统4. 执行（Execution）系统★ 感知系统感知系统是智能体“看／听／感知环境”的部分。论文提及四种主要方式：文本感知、多模态感知、结构化数据／信息树感知、工具辅助感知。- 文本感知（Text-Based）：环境以纯文本形式输入，LLM 直接处理。这种方式代价最低，但只适用于文本驱动的场景。- 多模态感知（Multimodal）：环境包含图像／视频＋文字，使用视觉‐语言模型（VLM）或多模态 LLM（MM-LLM）将视觉输入编码为与文本兼容的向量。- 结构化数据／信息树（Information Tree / Structured Data）：例如 GUI 的 Accessibility Tree、HTML DOM 树，将界面元素结构化地输入模型。- 工具辅助感知（Tool-based）：智能体调用外部 API／工具获取环境信息（如网页检索、数据库查询、传感器数据等）然后将结果反馈给 LLM。论文还指出感知系统的关键挑战：例如图像识别中模型可能“幻觉”对象、上下文窗口受限、高计算／延迟成本、数据收集困难等。★ 推理系统推理系统是智能体“思考／规划／决策”那部分。论文讨论了多种方法：- 任务分解（Task decomposition）：把大任务拆成子任务。包括“先分解再规划”（Decomposition first）和“交错分解”（Interleaved decomposition）两类。- 多方案生成与选择（Multi-plan generation & selection）：代理生成多个可能方案（如通过 Tree-of-Thought, Graph-of-Thought, LLM-MCTS 等）然后选择最优一个。- 反思（Reflection）：智能体在执行后或执行途中反思自己的决策／行动，识别错误并改进。甚至“预反思”（anticipatory reflection）在执行前预测失败。- 多智能体系统（Multi-agent systems）：将推理分为多个“专家”模块（Planning Expert、Memory Expert、Error Handling Expert 等），各司其职、协同完成。★ 记忆系统记忆系统使智能体不仅“即时反应”，还能“记住过去、用过去指导未来”。论文区分短期记忆与长期记忆。- 长期记忆（Long-term memory）：如将经验固化、使用 Retrieval-Augmented Generation（RAG）从外部知识库检索、将结构化数据（如 SQL 数据库）用于查询。- 短期记忆（Short-term memory）：通常是 LLM 的上下文窗口中的“当前任务状态”。- 应存储的数据类型：成功经验、失败经验、动作轨迹、环境反馈等。将“失败”经验也显式记录有助于避免重复错误。- 记忆系统的挑战包括：上下文窗口限制、检索噪声、长期记忆如何更新与维护、如何避免“记忆漂移”等。★ 执行系统执行系统是智能体“将内部决策落实为环境动作”的部分。论文谈到执行系统要支持工具调用、API／代码生成、物理操作、GUI 控制等。具体维度包括：- 工具与 API 集成（Tool and API Integration）- 多模态行动空间（Multimodal Action Spaces）——例如 GUI 控制、视觉界面操作、机器人控制、代码执行等。- 整合挑战（Integration Challenges）——例如如何让决策结果真正映射到动作、如何反馈结果、如何监控执行失败／成功。论文：arxiv.org/abs/2510.09244#ai创造营##程序员#

25. 【Claude Code任务系统深度解析：从待办清单到依赖感知的智能编排】做过复杂项目的人都有这种体验：你让AI帮你重构代码，它干到第四步突然忘了第二步是前置条件，开始做依赖未完成任务的工作。上下文丢失，前功尽弃。扁平的待办清单已经不够用了。Claude Code最新推出的任务管理系统彻底改变了这个局面。它本质上是一个依赖感知的编排层，能理解任务之间的阻塞关系，跨会话持久化，还能将工作分配给并行代理。这套系统有四个核心能力值得关注：第一，完整的依赖管理。任务可以阻塞其他任务，Claude在前置任务完成前不会启动被阻塞的工作。比如任务3被任务1和2阻塞，那它就必须等1和2都完成才能开始。再也不会出现“忘了先配置数据库”这种低级错误。第二，真正有效的持久化。会话内，任务状态能在上下文压缩时存活；跨会话，设置环境变量CLAUDE_CODE_TASK_LIST_ID后，任务能在完全独立的对话间保持。第三，代理分配与并行执行。任务被分配给命名代理，多个工作者同时启动，它们读写同一个任务列表却不会冲突。第四，可视化进度追踪。终端里按ctrl+t就能看到所有任务状态：已完成、进行中、待处理、被阻塞，一目了然。系统提供四个核心工具：TaskCreate创建任务，TaskUpdate修改任务状态和依赖关系，TaskGet获取任务详情，TaskList查看全局。依赖管理是这套系统的精髓所在。当你给任务3添加addBlockedBy: [“1”,“2”]时，意味着任务3必须等任务1和2都完成才能启动。一旦任务3完成，被它阻塞的任务4和5会自动解锁，变为可执行状态。这个机制从根本上杜绝了“在前置条件未满足时就开始工作”的问题。任务以JSON文件形式存储在~/.claude/tasks/目录下，每个任务一个文件，包含主题、描述、状态、阻塞关系等信息。这意味着你可以备份、版本控制，甚至用外部工具读写这些文件。代理分配的工作流程很有意思：Claude先创建任务并分配owner字段，然后启动代理并告诉它“你是fact-checker，去TaskList找分配给你的任务然后完成它们”。代理会自己发现任务、标记进行中、执行工作、标记完成。Claude可以在一条消息里启动多个代理并行运行。代理有四种类型：通用型能读写编辑搜索执行命令；Bash型只能跑终端命令，适合git操作和测试；探索型只读不写，用于快速了解代码结构；规划型也是只读，专注于设计实现策略。不同类型对应不同的速度和安全级别。模型选择上，haiku适合简单任务，sonnet适合大多数编码工作，opus适合复杂推理。什么时候该用任务系统？三步以上的多步骤工作、有依赖关系的任务、可能跨会话的工作、复杂重构或功能开发、需要多代理协作的场景。简单的一次性问题或单文件编辑就没必要了。这套系统的价值在于：它把Claude从“有时会跑偏的聪明助手”变成了“能用结构化方式管理复杂工作的编排者”。你获得了可见性、依赖约束、持久化、并行能力和清晰的责任归属。结构化能力决定了你能处理多大规模的复杂性。这个道理对人如此，对AI同样如此。x.com/nummanali/status/2014684862985175205

26. 这篇调查论文认为小型语言模型可以处理大多数代理任务，而大型模型仅在需要时介入。此设置可将常见工具任务的成本降低 10 倍至 30 倍。代理的工作主要是调用工具并产生结构化输出，而不是回忆大量事实。因此，路由器默认运行小模型，只有当置信度较低时才会升级到大模型。输出遵循验证器检查的严格 JSON 样式模式，这提高了正确性并减少了重试次数。这使得小型模型在函数调用和结构化数据方面可靠，同时响应更快、能耗更低。大型模型仍然处理长上下文合成、复杂的多跳推理、深度代码修复和更高风险的决策。对于常规步骤使用小模型，根据不确定性进行路由，并将大模型留给困难的情况。论文 – arxiv.org/abs/2510.03847论文标题：“代理系统的小型语言模型：架构、功能和部署权衡的调查”

27. 从失败中重生：一个 AI Agent 前端落地的真实复盘同步发布于博客：网页链接今天在 FEDay 上分享了一个 Agent 前端落地案例，核心内容是讲述了我参与的一个团队如何从"技术成功"走向"产品失败"，又如何在复盘中获得认知升级。这个故事的价值不在于成功的方法论，而在于那些踩过的坑和思维转变的过程。2025 年被称为 Agent 元年。Deep Research、Manus、Claude Code 相继发布，技术圈一片沸腾。很多团队都在问同一个问题：我们要不要做 Agent？在开始之前，我还是想讲一下我对 AI Agent 的定义：AI Agent（AI 智能体），是为了实现某个目标，循环调用工具的大语言模型。- 工具循环（tools in a loop）：模型调用工具 → 获取结果 → 继续推理- 有明确终点：为了达成目标，而不是无限循环- 目标来源灵活：可以来自用户，也可以来自另一个 LLM- 基础记忆能力：通过对话历史保存上下文信息朋友负责的团队面临的是一个真实的企业痛点：公司有完整的内部设计系统（Design System）和私有前端框架，但这些代码从未被 AI 训练过，通用模型根本无法直接生成符合规范的代码。目标看起来很清晰——做一个类似 Lovable 的工具，但用的是自己的 Design System。用户上传 Figma 设计稿或截图，Agent 自动生成符合内部规范的前端代码。听起来很美好，对吧？但挑战也很现实：- 要完整搭建一个 Agent 系统没想的那么容易，不仅要和模型交互，还要处理好用户交互，还有上下文工程- 要让模型理解和使用从未训练过的私有组件- 要在浏览器中实时预览生成结果- 出错了希望能自动修复由于团队之前没有开发过 Agent 相关产品，所以请我参与其中，提供技术咨询和方案建议。我第一个建议很现实：先跑通再优化—— 构建 Agent 最难的不是技术，而是完整跑通流程。我推荐他们基于 Claude Agent SDK 进行二次开发，而不是从零造轮子。一些关键理由包括：1. Claude Code 已经验证了它是可行的2. 开箱即用，内置工具足够满足绝大数场景3. 可以自定义工具、接入 MCP、自定义 Skill4. 可以接入国产兼容模型还帮着基于 Claude Agent SDK 快速搭建了一个原型系统。一些关键代码还开源在这里：网页链接这样很快有了个基本可用的 Agent。接下来就是解决代码的浏览器预览问题。一开始我们尝试用 Sandpack（浏览器端沙盒）做代码预览，结果发现复杂组件根本跑不起来，而且无法发挥 Agent 读写文件的能力。转向方案是给 Agent 一个本地文件系统——每个会话一个独立环境（虚拟机或目录），Agent 可以自由读取、修改、编译代码。这个决策让 Agent 的能力得到了最大化发挥。给 Agent 一个本地文件系统才能最大化的发挥 Agent 能力给 Agent 一个本地文件系统才能最大化的发挥 Agent 能力另一个难题就是如何让 AI 学会使用从未训练过的私有组件？其实就是把 Agent 当作新员工，用高质量文档和参考代码来教会它。我们把设计系统说明、组件列表、API 文档全部 Markdown 化，让 Agent 按需检索。高质量的参考代码本身就是最好的教材。而且完全不需要复杂的 RAG 系统，直接让 Agent 去基于文件检索搜索本地文档和代码就足够了。还有一个难题就是如何保证生成代码的质量，让代码能跑起来？为了保证代码质量，为 Agent 建立了一套"生成 → 验证 → 修复"的自动化闭环：Lint 静态检查、编译验证、视觉比对（借助 Chrome DevTool MCP 做截图对比）。一个节约主 Agent 上下文的技巧：把验证工具放入 Skill 或 SubAgent，避免污染主 Agent 的上下文。把这些问题都解决后，Agent 终于上线了。系统跑通了，Demo 很惊艳，但……很快就没什么人用。初期大家觉得新鲜，但很快就弃用了。开始和他们一起深度复盘，发现问题根本不在技术，而在产品逻辑与用户习惯的错位。通过对内部员工的调查访谈，很快就找到了原因：习惯阻力：设计师和产品经理更习惯在 Figma 里工作，而不是对着一个对话框。从舒适区（Figma）跳到陌生区（Agent 对话），这个门槛比想象中高得多。大部分甚至不知道该在聊天窗口写啥。80/20 瓶颈：Agent 能实现 80% 的效果，但剩下 20% 的修改成本极高。而往往就是那 20% 决定了能不能用。流程割裂：生成环境和开发环境是脱节的，无法利用现有代码，需要手动把生成的代码复制回项目，操作繁琐。团队意识到，他们最初问的问题是："如何构建一个设计系统 AI Agent？"这种提问方式让 Agent 变成了目的本身，为了技术而忽略了本质。正确的问题应该是："我们设计系统的最终目的是什么？"答案其实只有两点：在整个企业内实现设计规范的统一；实现开发效率的提升。设计系统只是手段，而非目的。思维转换：以 AI 为中心重新设计现有的流程是为人设计的：手动沟通、反复修改、人工确认，步骤繁杂，效率低下。未来的流程应该为 AI 设计：Input → AI Agent → Output，路径直接，效率高。这带来了两个新的设计原则：AI 友好：选择 AI 容易理解和操作的技术栈。轻量化：只保留 Design Tokens，基于 AI 友好的开源系统（如 shadcn/ui）进行扩展，而不是维护一套庞大的私有组件库。破局之道：从 Agent 到 Skill最关键的转变是：不要做一个独立的 Agent 平台，而是将能力嵌入现有的 AI 开发环境。旧模式是"独立 Agent 孤岛"——Agent 和开发者之间存在割裂，效率低下。新模式是"融入开发工作流"——把设计系统变成一种 Skill（技能），可以被通用的 Agent（如 Claude Code、Cursor）调用。Skill 的具体形态很简单：Markdown 文档（供 AI 查阅组件用法）+ 自动化脚本（用于初始化项目、自动安装和应用设计系统）。开发者在自己熟悉的 AI 开发环境里工作，当需要用到设计系统时，Agent 自动调用这个 Skill，生成的代码直接进入项目代码库。Skill 的具体形态很简单：Markdown 文档（供 AI 查阅组件用法）+ 自动化脚本（用于初始化项目、自动安装和应用设计系统）。开发者在自己熟悉的 AI 开发环境里工作，当需要用到设计系统时，Agent 自动调用这个 Skill，生成的代码直接进入项目代码库。可以参考：网页链接这个案例让我想到几个更深层的问题：1. 技术成功 ≠ 产品成功很多技术人（包括我自己）容易陷入"技术可行就是成功"的思维定式。但用户不会因为你的技术牛就买单，他们只关心能不能解决自己的问题、能不能无缝融入自己的工作流。2. 做 AI 产品要"以 AI 为中心"思考我们常说"以用户为中心"，但在 AI 时代，可能需要增加一层：以 AI 为中心设计工作流，再让用户享受这个高效流程的成果。不是让 AI 模仿人的工作方式，而是重新设计工作方式让 AI 更高效。3. Skill > Agent独立的 Agent 平台有天然的adoption障碍。把能力封装成 Skill，嵌入已有的通用 Agent 生态，可能是更务实的落地路径。这也是为什么 Anthropic 推出 web-artifacts-builder 这样的开源项目——它就是一个 Skill 的范例。4. 行动本身就是价值即使这个项目"失败"了，团队获得的认知升级是无价的。从模仿人类工作流到为 AI 重塑工作流，这种思维转变只有在实践中才能获得。最后我想说的是："去构建（Build）"。AI 时代，失败没什么，好过什么都没做。

28. 打造13个Claude Agent 互相 review 彼此↓ Reddit 一个开发者用 OpenClaw 框架搭建了 13 个 Claude Agent，让它们像真实团队一样工作：有人写代码，有人 review，有人测试，有人查安全漏洞。然后还互相 review 彼此的工作。 1 Writer Agent → 生成代码 2 Reviewer Agent → 逐行审查，对标 code review 标准 3 Tester Agent → 设计测试用例，验证逻辑 4 SecurityAuditor Agent → 扫描安全漏洞 5 Optimizer Agent → 性能优化建议 6 DocumentWriter Agent → 生成 API 文档 7 QA Agent → 最后一关，综合检查 ... + 6 个其他专业角色 vs. 链式流程（A→B→C），这个设计采用质量门控流程。Reviewer 必须 approve 才能进入下一阶段。出问题时反馈重做。成本控制？看起来 13 个 Agent 全力跑，tokens 肯定爆炸。但这个哥们用了几个聪明的招： 1. Context 优化 Writer 不需要看 test cases，Tester 不需要看文档。每个 Agent 只加载相关上下文。这一招可以干掉 80% 冗余 token。 2. 采样策略不是每一行代码都通过全部 13 个 Agent。核心路径 100% 检查，非关键路径采样。 3. 缓存和复用已审查过的代码片段不重复审查。测试用例库复用。架构决策缓存。结果呢？ - 单个开发者 Claude Code：每天 5-20刀 - 13 个 Agent 团队：每天 15-30刀（成本增加不多，质量翻倍）实际对比维护 10 万行代码库： 1. 传统手工做法 - 人工 code review：8 小时 - token：50-80刀 - bug 漏过率：5-10% 2. 13 个 Agent 团队 - 总耗时：30 分钟（Architect 规划 → Writer 并行生成 → Reviewer 自动审查 → 全流程质量门控） - token：20-25刀 - bug 漏过率：<1% 为什么这个方案特别？ 1. 角色化 > 能力化不是「给 Claude 一个超级 Prompt 让它什么都会」，而是「给每个 Agent 一个明确的职责」。 Writer Prompt：「你是代码作者，你的工作是...」 Reviewer Prompt：「你是资深 code reviewer，标准是...」角色专业化自动带来质量提升。 2. 质量门控自动化传统 code review 是人工 bottleneck。Agent review 是自动化 + 可扩展的。 3. 知识积累每个 Agent 的执行历史（什么被 reject、为什么）可以持续优化 Prompt。这是机器学习意义上的反馈循环。 4. 工程意义这不是「用 AI 替代人」，而是「用 AI 团队协作替代个人英雄主义」。更接近真实团队的工作方式。背后的思想转变从「Prompt Engineering」→ 「Architecture Engineering」以前我们花时间优化单个 Prompt，试图让一个 AI 更聪明。现在聪明的做法是设计系统，让多个 AI 通过角色分工和质量门控，集体产出更高质量的结果。原文：www.reddit.com/r/ClaudeAI/comments/1rga7f5/how_i_built_a_13agent_claude_team_where_agents/ #how i ai##程序员#

29. 【Codex Subagents：136个AI专业分身让编程效率起飞】快速阅读：一个开源项目收录了136个针对Codex的专业化AI助手，覆盖从前端开发到安全审计的各个领域。每个Agent都有独立的上下文窗口和专门指令，能像真实团队成员一样处理特定任务。关键是这些Agent不会自动触发，需要明确指派。—AI编程助手的进化方向可能不是更强的单一模型，而是一群各司其职的专家。这个叫awesome-codex-subagents的GitHub仓库里，藏着136个经过精心调教的AI分身。前端有React专家，后端有Go并发高手，安全审计、性能优化、数据库调优，甚至Active Directory管理都有对应的Agent。每个Agent都是一个.toml配置文件，指定模型、沙盒权限和专业指令。比如security-auditor用gpt-5.4处理深度推理任务，search-specialist用更快的gpt-5.3-codex-spark做信息检索。审查类Agent设为只读权限，开发类Agent可以修改代码。这种设计既保证专业性，又控制权限范围。GitHub: github.com/VoltAgent/awesome-codex-subagents#AI创造营##人工智能#

30. Multi-Agent Collaboration via Evolving Orchestration这篇论文提出了一个极具启发性的多智能体协作框架：让整个多智能体系统由一个可学习的 “木偶师（Puppeteer）” 动态调度所有智能体（Puppets）这个框架，旨在通过解决现有系统固有的静态组织结构问题，来优化大型语言模型（LLM）的多智能体协作。其核心思想是利用一个集中式协调器，像木偶师一样，根据任务的动态变化来动态指导和调度专业化代理的激活顺序。这种协调器通过强化学习进行训练，其奖励函数旨在同时最大化解决方案的质量和计算效率，例如减少令牌消耗。实验结果表明，该方法在各种任务中实现了卓越的性能，同时显著降低了计算开销，证明了其可扩展性。分析进一步揭示，经过优化的协调机制促使多智能体系统形成了更紧凑且具有循环反馈的推理拓扑结构，超越了传统的链式或树状模型。1 研究提出的问题：当前 MAS 存在的根本瓶颈1）当前大多数多智能体系统采用静态结构，例如固定流程、固定 DAG、固定角色协作方式。2）当任务复杂度提升或智能体数量增加时，静态架构会出现协调开销大、冗余调用多、效率下降等问题。3）某些智能体在任务中实际贡献有限，但静态结构依然会触发它们，导致 Token 浪费甚至干扰推理。4）在软件生成、复杂问答、开放域推理这些任务中，多智能体之间真正有效的协作模式往往因任务不同而变化，这很难靠人工预设计完成。因此，论文提出一个关键问题：能否让一个系统自动“学会”如何调度智能体，而不是用固定协作结构？2 核心思想：木偶师式动态调度（Puppeteer Paradigm）智能体是“木偶”，一个中央控制器是“木偶师”，其任务是在推理过程中动态决定谁上场、谁退场。整体架构包含三个关键点：1）让一个中央 orchestrator（木偶师）在每一步根据当前任务状态，选择一个最合适的智能体执行下一步推理。2）这个 orchestrator 会在任务执行后得到奖励（正确性 + 计算成本），并通过强化学习不断优化调度策略。3）虽然过程是序列化的（每步一个 agent），但整个推理轨迹可以折叠成一个动态生成的有向图，即“推理图谱（Graph-of-Thoughts）”。这意味着：1）系统可以随着任务自动形成树结构、图结构、循环结构等多种协作拓扑。2）协作不再依赖预定义流程，而是任务驱动、自适应、持续演化的。3 方法框架详细拆解论文的方法分成两个关键模块：3.1 动态编排（Dynamic Orchestration）1）将每个智能体表示为一个三元组（模型、推理模式、可用工具）。2）将多智能体协作建模为一个集中式决策过程：木偶师在时间 t 根据全局状态 Sₜ 选择一个 agent 执行推理。3）每个 agent 输出结果后更新全局状态，并交由木偶师继续选择下一个 agent。4）当遇到终止条件（例如 Terminator agent）时，系统停止并输出最终结果。这个决策过程严格满足马尔可夫性，天然适合强化学习：P(aₜ₊₁ | S₀, ..., Sₜ₊₁) = P(aₜ₊₁ | Sₜ₊₁)因此 orchestrator 可以真正做到基于实时状态的动态调控。3.2 自适应演化（Adaptive Evolution）论文使用 REINFORCE 算法优化 orchestrator 的策略 π：1）任务完成后一次性给出奖励 r（正确 1，错误 0，开放任务得分区间为 [0,1]）。2）每一步会设定成本 Cₜ（Token 或 FLOPs）。3）总回报为 r 减去 λ·成本，λ 是可调的效率权重。该设计促使 orchestrator 学会：1）更倾向使用高性价比的智能体2）避免冗余推理步骤3）尽快调用 Terminator 停止推理4）长期形成紧凑而高效的协作结构4 实验结果解析：性能提升 + 成本下降“双赢模式”1） Puppeteer 在几乎所有任务上都获得显著性能提升2）强化学习后的 evolved 版本比初始版本显著更强3）在 Titan 模型空间中，平均性能从 0.6893 提升到 0.77314）更重要的是 Token 开销随着训练反而下降，不是上升这与过去多智能体研究经常出现的“调用越多越好”形成鲜明对比。5 拓扑结构的演化：从链式到紧凑循环论文一个非常有趣的发现是：随着 orchestrator 训练，多智能体协作拓扑从松散 → 紧凑，从树结构 → 图结构，并出现大量循环。具体表现为：1）图密度增加2） agent 之间的循环次数增加3）反复调用少量“核心智能体”的情况越来越多4）冗余 agent 被逐步淘汰5）推理链路更短、更集中、更有效其背后的原因非常符合直觉：1）强 agent 往往值得重复调用2）循环（自我检查、跨 agent 校验）有益于复杂推理3）扩散式的树结构容易浪费 token4）强化学习会惩罚冗余推理，鼓励形成高效闭环可以认为，这是一种机器自动学习推理结构的过程，类似于“推理图谱的自组织”。#ai创造营# #科技#

31. #IT那些事儿# 比可汗学院和慕课还可汗：AI 同学吵起来了，这才是真正的多 Agent 课堂！清华研究团队开源的这个 OpenMAIC，让我惊了，感觉比可汗学院和慕课还可汗。你发一句话（图一）或一个文件，几分钟内就自动生成一堂完整的 AI 多 Agent 互动课堂——AI 老师语音讲解 + 白板实时画重点（图二），AI 同学和研究生助理跟你有问有答引导热烈讨论，有的“同学”思辨能力强，有的“同学”靠直觉（图三），实时测验、项目式学习（PBL）全都有，包教包会，还能用麦克风直接对话。OpenMAIC 和小龙虾一样，也是“模型无关（model-agnostic）”架构，如果在本地搭建推荐配置高性价比推理模型（如 Gemini Flash），不过对于不同角色可以用不同模型（老师 / 学生 / 助教），这样能省点钱。OpenMAIC 技术本质上是：RAG + 多Agent系统 + 教学流程建模 + 多模态交互。它的核心创新是多Agent编排。每个 Agent 都是一个 LLM prompt + memory，通过 graph 控制调用顺序，支持循环（讨论 → 修正 → 再讲），这就是为什么能看到“AI同学吵起来”（图四）。我看很多人第一反应就是那 AI 幻觉怎么办？是啊，如何从工程上解决课堂多 AI Agent 的一致性和收敛性问题呢？首先，在多 Agent 课堂里，幻觉不是 bug，而是系统性风险！因为这个课堂里有多角色（老师 / 学生 / 助教）、长上下文（整堂课）、开放问题（学生提问），这比单轮问答难一个数量级，一旦一个 Agent 说错，其他 Agent 接着“合理化”，就会形成共识，强化错误。其次，我在研究过的 SWE-CI 问题中就曾说过“上下文漂移 + 约束遗忘”（参见：网页链接），那么在多 Agent 课堂里就会表现为越讲越偏和讨论跑题。那么，如何解决呢？猜测大概要分六层防护。第一层，RAG Grounding（检索增强生成“锚定”在可验证的外部真实数据源上）第二层，角色降权（主要是 AI “学生”）第三层，提高AI“助理”的校验机制，或者单独增加一个裁决 Agent第四层，结构化输出（防止漂移）第五层，建立课堂“收敛机制”第六层，全局一致性监控总结一下，要想抑制多 Agent 课堂的幻觉，必须要求（比如以 SKILLS 的方式）：1）所有知识必须引用来源2）每一模块必须包含“总结 + 测验”3）学生 Agent 不能给结论4）加入 Verifier Agent 做一致性检查OpenMAIC 的出现，标志着 AI 教育从“单点问答”迈向“系统性课堂编排”的质变。它的真正价值，不在于“让 AI 会讲课”，而在于它首次把教育问题转化为一个可工程化的多 Agent 系统一致性与收敛性问题——有争论、有纠错、有收敛。但这也意味着，任何想在教育场景中认真落地多 Agent 系统的团队，都必须把"幻觉治理"当作头等大事来设计。上文提到的六层防护体系，本质上是在回答同一个问题：如何让一群 AI 在开放主题编排和开放对话中，仍然对真理负责？这不只是 OpenMAIC 的工程挑战，也是整个 Agentic AI 时代的核心命题。教育场景，恰好是压力测试它的最好战场——因为学生不会假装听懂，错了就是错了。

32. 在研究编程Agent，Agent核心就几十行代码，那剩下的几万行到底在解决什么问题？

33. 2026年AI主线换了！这5大趋势必须看清。 #大咖观察 #红衣聊AI #趋势风口 #人工智能

34. 语音智能体商业落地的教训、经验与实践｜李沐硅谷101年度线下大会演讲（全英）

35. AI也可以组建团队了港大开源的新项目ClawTeam感觉像是让AI Agent从单机到了集群，不同于当前主流的单Agent工具，ClawTeam引入了领导型Agent。当我们下单目标，它就会自主将复杂任务解构为子任务。从开发到部署的全流程自动化，ClawTeam的全栈闭环将原本需要人工干预的DevOps流程转化成了Agent群体的内部协作。如果说OpenClaw解决了“手”的问题，ClawTeam就是在试图解决“脑与神经网络”的问题吧 #ai##ai前沿速递##微博兴趣创作计划#

36. 上个月，谷歌悄然发布了五篇关于AI Agent的重磅论文，连续五天每天一篇，深入探讨了Agent的构建、评估、安全和部署等核心问题。没有大张旗鼓，250多页的技术细节静静铺开，值得每个AI从业者认真研读。这五篇论文的核心内容总结如下：1. 什么是Agent？谷歌重新定义了Agent，强调它们能力的演进和为何大多数Agent一离开演示环境就崩盘。现有Agent更像是复杂的工作流和工具编排，而非真正的自主系统。kaggle.com/whitepaper-introduction-to-agents2. 工具和MCP（多能力协议） MCP允许服务器无须用户同意即添加工具，虽然增强了能力，但也带来边界风险。换句话说，Agent仍然无法“感知”世界，只是更有效地调用API。kaggle.com/whitepaper-agent-tools-and-interoperability-with-mcp3. 记忆问题真正的记忆不是简单的上下文窗口、检索增强生成（RAG）或向量存储，而是一个动态、结构化的长期记忆，影响未来推理和行为。谷歌提出了会话拼接和动态上下文窗口，但本质差距依然存在。kaggle.com/whitepaper-context-engineering-sessions-and-memory4. Agent质量评估评价不仅是输出正确与否，更重视Agent的推理过程。论文提出了正确性、鲁棒性、重复性、多步稳定性和幻觉控制等指标，揭示当前架构在这些方面的脆弱。kaggle.com/whitepaper-agent-quality5. 从原型到生产构建Agent简单，信任它完成真实任务困难。论文详细说明了沙盒环境、安全护栏、评估循环和人工干预机制，反映出系统的不确定性和脆弱，需要大量安全网。kaggle.com/whitepaper-prototype-to-production深度思考：谷歌的努力展现了巨大的工程投入，但他们依然被“语言模型物理学”所限制。试图通过不断修补LLM来实现真正的Agent，是在用“token机”伪装认知。真正的自治智能需要内在的组织、自我预测、力量感知和发展结构，而这些是现有LLM架构根本不具备的。这五篇论文不仅是技术文档，更是行业缺失的蓝图。它们提醒我们，构建Agent不仅是搭建工具链，更是要建立能够自我调整、自我稳定的认知架构。谷歌在工程上走得很远，但未来的Agent革命还在于基础架构的重塑。x.com/techNmak/status

37. 这篇文章《Agent Design Is Still Hard》写的太好了，值得逐行细读！看完的6个感受：1. 如果你自己写 agent，建议尽量直接用底层 SDK（而不是高层抽象）；2. 明确缓存策略 — 尤其是对大模型 + 多步骤任务，非常关键；3. 引入强化机制（reinforcement）和 sub-agent / sub-inference，以提高 agent 的稳定性／可靠性；4. 如果你的 agent 会生成实际输出 (邮件、文件、报告等)，考虑用专门的 output tool，而不是把 “输出内容” 混在 agent loop 的消息里；5. 在设计共享状态 (shared state) 时，引入类似“虚拟文件系统 (virtual file system)”的机制，会让系统更模块化，也更适合复杂任务 + 多工具调用；6. 最难也是最重要的一点 —— 测试与评估 (testing & evals) 是 agent 系统工程中最棘手的问题，目前还没有通用／优雅的解决方案。原文转译如下：Agent 设计依然很难我觉得现在是时候写写我新学到的一些东西了。大部分内容与构建 agent 有关，少部分与使用 agent 式编程工具有关。总结：构建 agent 依然混乱。只要真正开始用工具，SDK 抽象就会崩。缓存如果你自己管会更好，但不同模型间差异很大。强化（reinforcement）比预期承担更多“驱动”任务，而失败必须严格隔离以避免把循环带偏。通过类似文件系统的共享状态是非常重要的基石。输出工具比想象中更棘手，模型选择依然强依赖任务类型。一、选择哪个 Agent SDK？当你构建自己的 agent，你可以选择直接使用 OpenAI SDK、Anthropic SDK 等底层 SDK，也可以选择更高层的抽象，例如 Vercel AI SDK 或 Pydantic。我们之前做的选择是采用 Vercel AI SDK，但只用其 provider 抽象，然后基本上自己驱动 agent loop。现在来看，我们不会再做这个选择。Vercel AI SDK 本身没有问题，但当你要真正构建 agent，会发生两个我们没预料到的事：第一，不同模型之间的差异大到不得不自己构建 agent 抽象。我们没发现任何 SDK 提供的抽象能真正匹配 agent 的需求。部分原因是：虽然 agent 的基础设计就只是一个 loop，但工具集不同会带来微妙差异。这些差异会影响抽象是否容易找到（比如缓存控制、不同的强化需求、工具提示、provider 侧工具等）。因为“正确抽象”现在还不清晰，所以使用平台的原生 SDK 让你掌控更多。而很多高层 SDK 要你构建在它们的抽象之上，最后这些抽象可能并不是你真正需要的。第二，当涉及 provider 侧工具时，我们发现使用 Vercel SDK 非常困难。消息格式尝试统一，但并不真正奏效。例如 Anthropic 的网页搜索工具会频繁破坏 Vercel SDK 的消息历史，我们至今还没完全搞清原因。此外，在 Anthropic 的情况下，缓存管理在其原生 SDK 中比在 Vercel 中容易得多，而且错误信息也更清晰。也许未来会变化，但至少现在，我们不会在构建 agent 时使用抽象层，除非整个生态已经稳定。对我们来说，目前抽象层的收益远远不足以抵消其成本。也许别人已经解决这个问题了。如果你看了觉得我错了，欢迎发邮件，我非常愿意学习。二、关于缓存的经验不同平台对缓存的处理方式非常不同。大家已经讨论过很多，例如 Anthropic 的缓存是收费的，并且需要你显式管理缓存点，这会从 agent 工程角度完全改变你的交互方式。一开始我觉得手动管理缓存很蠢：为什么平台不自动管理？但现在我完全反过来了，非常喜欢显式管理缓存。它让成本与缓存利用率都更可预测。显式缓存能让你做一些否则很难做的事情。例如，你可以把会话分叉成两个不同方向并行执行。你也能进行上下文编辑。最佳策略尚不明确，但你确实有更多控制权，而且这种控制权非常宝贵，也让你更容易理解 agent 的成本结构。你可以更好地预测缓存命中率，而其他平台我们发现经常是碰运气。我们在 Anthropic 的 agent 中的缓存策略很直接：一个缓存点放在 system prompt 后；两个缓存点放在对话开头，并随对话尾部不断前移；除此之外还有一些小优化。因为 system prompt 和工具选择必须尽可能静态，我们会在之后的动态消息里提供时间等信息，否则会破坏缓存。我们在循环中也更多利用强化。三、Agent Loop 中的强化每次 agent 调用工具，你不仅可以返回工具的执行结果，还可以向循环中注入更多信息。例如，你可以提醒 agent 宏观目标、子任务状态，也可以在工具失败时提供如何让工具调用成功的提示。另一个用途是在后台状态发生变化时告知系统。如果 agent 会使用并行处理，你可以在每次工具调用后注入状态变化信息。有时 agent 自我强化就够了。例如在 Claude Code 中，todo write 工具本质上是个自我强化工具——它只是接收 agent 给出的一组任务，再原样返回。这基本就是个 echo 工具，但却足以让 agent 推进得比只在上下文开头给任务列表要好得多。我们也使用强化来告诉系统环境是否在执行过程中发生了问题。例如，如果 agent 在某一步失败并重试，但恢复基于损坏的数据，我们会注入消息告诉它应该回退几步重新来。四、隔离失败如果你预计代码执行中会有很多失败，有机会把这些失败从上下文中隐藏。主要方式有两种。第一，把可能需要多次迭代的任务单独运行。你可以在子 agent 中运行任务直到成功，再只把成功结果（可能带一段失败策略摘要）回传。让 agent 看到一些失败尝试是有价值的，因为它可以在后续任务中利用这些信息避免重复错误。第二，并非所有模型都支持，但 Anthropic 支持上下文编辑。我们还没取得太多成功，但觉得非常值得继续探索。上下文编辑理论上可以保留更多 token 用于后续循环。例如你可以从上下文中删除对解决问题没有帮助的失败输出。但如前所述，让 agent 知道“什么没成功”有价值，只是不需要保留全面状态。唯一的问题是：上下文编辑会自动使缓存失效，这是无可避免的。因此是否值得这样做往往难以判断。五、子 Agent / 子推理（Sub Inference）如我之前提过，我们的 agent 多基于代码执行与代码生成。这要求 agent 有一个公共的数据存储位置。我们采用文件系统——在我们这里是虚拟文件系统。为了支持子 agent 或子推理，这要求所有工具都能访问这个文件系统。你应该尽量构建没有死路的 agent。所谓“死路”是指任务只能在某个特定工具内部继续。例如你做了一个图像生成工具，但它只能将图像交给另一个特定工具使用，那就会造成死路。如果你希望把生成的图像打包成 zip，需要代码执行工具能读取这些图像。因此必须让图像生成工具把文件写到虚拟文件系统，而代码执行工具也能读同一位置。反之亦然。你可能需要代码执行工具解压 zip 文件，然后让推理工具描述这些图片，之后再回到代码执行工具继续处理。文件系统就是实现这一点的机制。但这要求所有工具都支持从虚拟文件系统读取路径。因此“ExecuteCode” 工具和 “RunInference” 工具应该都能访问同一文件系统。六、输出工具的使用我们的 agent 不是一个聊天式系统。它最终会输出给用户或外部世界一些内容，但中间所有消息通常不会暴露出去。问题是：它如何生成最终输出？我们有一个专门的输出工具，agent 必须显式调用它来对人类输出。我们通过 prompt 告诉它何时使用该工具。在我们的场景中，输出工具负责发送邮件。但这反而带来很多意外问题。最难的是：相比直接在 agent loop 中输出文本，让输出工具生成“最终信息”时很难控制语气与措辞。我不知道为什么，但推测与模型训练方式有关。我们尝试过让输出工具再调用一个小模型（如 Gemini 2.5 Flash）进行文本润色。但这增加了延迟，而且反而降低输出质量。部分原因是小模型没完整上下文，无法正确措辞。而为了给它更多上下文又会变得昂贵，而且仍不能解决所有问题。有时还会泄露我们不想让最终用户看到的中间步骤。另一个问题是 agent 有时根本不调用输出工具。我们强制要求记录输出工具是否调用过。若循环结束前还没调用，我们会注入强化消息提醒它调用。七、模型选择总体上我们的模型选择最近没有太大变化。Haiku 和 Sonnet 依然是目前最好的工具调用模型，因此非常适合作为 agent loop 的主模型。它们对 RL 的行为也比较透明。另一个明显选择是 Gemini 模型。我们在主循环中并未在 GPT 系列上获得太多成功。对于子工具（例如需要额外推理的工具），我们目前主要用 Gemini 2.5——尤其是处理长文档、PDF、图像信息抽取等任务。特别是因为 Sonnet 系列容易被安全过滤器挡住，处理图像比较麻烦。另外一个显而易见的结论：token 价格并不能决定 agent 的整体成本。工具调用更强的模型能用更少 token 完成任务。有些模型 token 更便宜，但不一定在 loop 中更省钱。总的来说，过去几周变化不大。八、测试与 Evals测试与评估是我们认为最难的问题。这并不意外，但 agent 的特性让问题更棘手。与 prompt 不同，你无法在某个外部系统里轻松做 eval，因为需要提供太多上下文。这意味着 eval 必须基于观测数据或在真实测试运行中进行仪表化。目前我们试过的所有解决方案都没让我们满意。遗憾的是，现在我们还没有找到让人真正开心的 eval 方法。希望能尽快找到，因为这已经变成构建 agent 时最令人沮丧的问题之一。九、Coding Agent 的一些更新关于编码 agent，我的体验没有太多变化。主要的新点是我在试用 Amp。原因不是它一定比我现用的 agent 更强，而是我非常喜欢他们对 agent 的设计方式。从他们公开内容能看出，他们的子 agent（如 Oracle）与主循环交互方式非常优雅，而今天市面上很少有框架能做到这一点。这也是我用它来验证不同 agent 设计方式的原因。Amp 和 Claude Code 一样，让人感觉是“使用者自己做的产品”。行业里并非所有 agent 产品都有这种感觉。十、最近读的东西下面是一些我觉得值得分享的内容。1. 《What if you don't need MCP at all?》：Mario 认为很多 MCP 服务器过度工程化，工具过多占用上下文。他提出一种极简浏览器 agent 方案：只依赖简单 CLI 工具（start、navigate、evaluate JS、screenshot），不仅 token 使用小，而且流程更灵活。我据此做了一个 Claude/Amp 的 skill。2. 《The fate of "small" open source》：作者认为微型开源库时代正在结束，因为平台 API 与 AI 工具足以按需生成简单实用工具。对此我非常认同。3. 《Tmux is love》：没有文章，但结论是 Tmux 很棒。如果你的 agent 要与任何交互式系统工作，都应该考虑添加 Tmux 能力。4. 《LLM APIs are a Synchronization Problem》：这是我最近的一个发现，内容太长写成了另一篇文章。#ai创造营# #程序员# 黄建同学的微博视频

38. 硅基流动杨攀：2026 年最大的创业机会，是给 Agent「造基建」

39. 我还常问另一个问题：ReAct 为什么在某些任务上不如 Plan-then-Act？1）ReAct 是“边想边做”，适合探索型任务，但任务结构混乱时会陷入局部最优。2）Plan-then-Act 是先全局规划，再执行步骤，适合高度结构化的任务。3）面试时可以说：ReAct ≈ 实时适应能力强Plan-then-Act ≈ 全局规划能力强工程中可以将两者结合：先由 Planner 做长规划，再由 ReAct worker 执行细节。

40. AI Agent 规模化落地最大障碍是技术还是商业模式？

41. Clawdbot 之后，我们离能规模化落地的 Agent 还差什么？

42. Claude Code subagent vs.Agent Teams vs. worktreeClaude Code支持多Agent协作，但里面的sugagent、Agent Teams、git worktree 概念容易混淆，好像都能并行协作开发。大多数开发者的错误做法是：把所有多Agent任务都用Agent Teams，或者把简单的工作也劲头十足地搞worktree，结果代码复杂度爆炸。1. Claude Code官方文档现在把它分成三个清晰的层级：层级1：Subagent（会话内辅助）适用场景：在当前编码会话内部创建临时任务特点：轻量级、快速、无需通信开销例子：「帮我写单元测试」「重构这个函数」「生成API文档」本质：一个主Agent指挥多个临时小助手，完成当前任务成本：低，通信延迟小层级2：Agent Teams（需要Agent间通信的并行任务）适用场景：多个Agent需要真正协作、信息交互特点：Agent有各自的记忆、上下文、角色定位例子：前端Agent + 后端Agent + DevOps Agent 协同开发一个微服务架构本质：真正的「团队」，每个Agent有独立决策权成本：高，需要复杂的通信协议和状态管理层级3：Git Worktree（轻量并行选项）适用场景：传统多分支开发，手动协调特点：完全依靠Git，不需要Agent间通信例子：同时开发feature1和feature2，用两个worktree分离代码树本质：操作系统级别的并行，Agent各自独立运行成本：中等，但需要手动协调merge2. 实战建议：1）刚开始用Claude Code？用Subagent。让一个主Agent指挥，足够了。2）小团队开发微服务？用Agent Teams，但不要超过3个Agent（通信成本会爆炸）。3）大型项目长期并行？用Worktree，保持简单，让人类开发者协调。大多数人的错误是高估了自己的需求，直接跳到Agent Teams。结果是Agent间通信变成性能瓶颈，不如一个聪明的Subagent快。3. 背后的工程思想这个三层设计反映了一个深层原则：越高级的能力，越要谨慎使用。Subagent看似简单（一个主Agent内部）但足以解决90%的任务。Agent Teams强大但需要精细的通信协议。Worktree原始但极其稳定。官方的建议其实是在说：从最简单的方案开始，只在确实需要的时候才升级。这叫做「渐进式能力提升」。很多开发者喜欢一上来就用最强的功能，结果代码难以维护、Agent间延迟高、调试成本爆表。明确边界后，选择变得简单了。官方文档：code.claude.com/docs/en/agent-teams#HOW I AI# #程序员#

43. 组织本身要成为「可计算代码」了？！1. 什么是智能体组织（Agentic Organization）？你了解什么是智能体组织吗？智能体组织看似新潮，但其实在触及组织管理的本质问题——组织中自主决策和信息流动的本质。1）传统定义：一个组织由人组成，通过等级制、流程、制度来协调众多个体的行动。2）智能体组织的定义：一个组织由「人+AI Agent混合体」组成，通过分布式自主决策和实时反馈来优化整体目标。关键区别在这里：1）传统公司：人做决策，决策流动形成信息链，从CEO→部门→执行层2）智能体组织：Agent做决策，Agent之间通过协议（非层级）交互，形成决策网络这不是自动化的升级，而是组织结构本身的范式转变。2. 为什么传统公司本质上是低效的？传统公司的低效来自三个根本缺陷：1）信息延迟和失真一个CEO要做战略决策，需要的信息来自：数据部门→分析师→部门经理→VP→CEO。每一层都有信息压缩和解释权。CEO拿到的信息，已经被人为过滤七八次。数学上讲，这是一个指数衰减的信息流。假设每层信息保留度是80%，经过7层后，CEO拿到的信息保留度只有0.8^7 = 21%。也就是说，CEO做决策时，只基于原始信息的1/5。智能体组织里，数据直接流向Agent，Agent基于完整信息做决策。信息流变成了常数而不是指数衰减。2）知识孤岛营销部和工程部各有各的工作流和隐性知识。营销知道什么样的用户容易转化，工程知道什么样的架构容易维护，但两个知识很难交汇。为什么？因为跨部门对话的成本太高了——开会、邮件、官僚流程。所以大多数500人的公司，真正在创意工作上的人可能只有5%。3）决策周期长从识别问题→汇报→批准→执行，通常需要2-4周。而竞争发生在毫秒级别。这意味着传统公司永远比市场慢一拍。智能体组织的Agent可以秒级做决策（当然要有清晰的目标和约束）。3. 智能体组织的核心机制是什么？不是AI替代人，而是「决策权的分布式转移」。新的组织架构三元素：1）面向智能体Agent的架构传统：金字塔。信息上升，指令下降智能体：网格/编队。Agent之间通过协议而非报告关系交互具体例子：- 营销Agent知道今天转化率下降- 工程Agent知道今天部署了新的推荐算法两个Agent能自主协商这是否相关，而不需要人工干预这背后的理论是Game Theory——多个自主体在约束条件下博弈，寻求纳什均衡（Nash Equilibrium）。McKinsey的研究指出，智能体组织本质上是应用博弈论的组织设计。2）Org Code（可计算的组织代码）Karpathy说：所有的组织习惯和流程，都是Org Code。传统公司：我们的决策流程是这样的（人工、缓慢、隐性）智能体组织：我们的Org Code是这样的（可编程、透明、可优化）如果组织流程能被写成代码，就能被复制（fork）、优化、和即时调整。这是微观经济学里的制度重构。以前制度是隐性的、刚性的，现在变成了显式的、软件代码一样灵活。3. 治理延迟这是SSRN最近发表的一个关键概念：治理延迟 = Agent执行速度 vs 组织干预速度的时间差。比如：传统公司：Agent做错决策，人发现这个错误需要2周，然后审批修正需要1周 → 总共3周的损失智能体组织：通过预先设计的管理约束，在Agent的决策权限中嵌入约束条件，错误被提前防止，而不是事后修正这背后的理论是Threshold-Based Authority——给Agent设定清晰的决策边界，超过边界自动触发人工审查。4. 为什么这种变化必然到来？从竞争环境变化的角度：过去：竞争基于谁的决策质量更高（需要更聪明的CEO）现在：竞争基于谁的决策速度更快（需要更快的决策系统）这是一个从速度维度到时间维度的转变。在秒级、毫秒级的竞争中，传统组织已经输了。从技术可能性的角度：现在，Claude、GPT-5等模型的能力已经足以支撑Agent做独立决策而不仅仅是推荐。当技术能力和商业需求对齐，转变就不可避免了。5. 智能体组织会面临什么挑战？1）治理延迟的困境Agent执行速度是毫秒，人的干预能力是小时。如何确保Agent做出的决策在规则内正确，但战略上也正确？SSRN论文指出：仅仅遵守规则还不够。一个Agent可以在所有约束下正确决策，但决策的组合可能导致战略目标偏离。这需要更高层的Meta-Governance——对Agent的整体决策模式进行监督，而不仅仅监督单个决策。2）组织 DNA 的重新编写Berkeley的CMR论文指出：智能体组织不是在旧组织上加Agent，而是要从设计阶段就考虑Agent。这意味着：新公司可能比老公司有3-5倍的竞争优势（新生儿vs进化的恐龙）老公司的转型成本极高，因为要改变的不只是流程，而是组织的DNA3）Agent 协作的博弈论陷阱多个Agent在网格结构中交互，本质是多人博弈。如果激励结构设计不当，可能陷入：- 每个Agent都在最优，但整体次优- 搭便车问题- Agent之间的意外冲突McKinsey的「Accountability by Design」强调，必须在Agent的激励机制中，嵌入整体目标优化而不仅仅是个体最优化。6. 智能体组织时代，人的角色是什么？角色转变：- 从做决策的人 → 设计决策系统的人- 从执行计划的人 → 监督Agent编队的人- 从连接信息的人 → 优化信息流的人可能出现的新岗位：- Agent编排师 — 设计Agent的目标、约束、协作协议的人- 混合经理（Hybrid Manager）— 领导人+Agent混合团队，权衡自主和控制- 治理架构师 — 设计Agent间的制约机制，确保没有系统性风险- AI教练 — 帮助传统员工理解如何与Agent协作可能消失的岗位：- 连接点型工作（会议协调、流程对接、信息中转）- 纯执行岗（那些按流程办的工作）这意味着：不是AI替代人，而是人的工作内容彻底改变。适应的人会获得3-5倍的效率提升，不适应的人会被淘汰。7. 总结一下1） Org Code 的可复制性改变了竞争格局传统公司的竞争优势来自经验和人才（都是长期积累）。Agentic公司的竞争优势来自Org Code（可以快速复制和迭代）。这意味着：第一个搞清楚赚钱的Org Code的公司，可以在3个月内复制到全球10个市场。而传统公司需要3年招聘和培训。2）组织变成了可计算的这是历史性的转变：组织首次从人工进化到编程。从人类文明的角度：- 工业革命：体力被机器替代- 信息革命：信息处理被计算机替代- Agentic革命：决策和协调被Agent替代每次都是一个小比例的人掌握新工具，而大多数人被淘汰。这次的速度会是最快的。3）组织管理学的范式转变从科学管理+人力资源到Agent设计+博弈论优化。这意味着：未来的CEO不需要懂人力资源管理，而需要懂智能体架构。组织管理的技能集将完全改写。你准备好了吗？如果你在一个传统组织工作，现在要思考三个问题：1）我的工作，是连接点型还是创意型？如果是前者，你有2-3年的窗口期，赶紧学如何设计智能体系统。如果是后者，你反而更安全，因为创意工作不容易被Agent替代，但你需要学会与Agent协作。2）我的组织，是否已经开始思考Org Code？如果没有，你们的竞争优势在缩小。没有可计算的组织代码，就没有快速迭代和复制的能力。3）在Agentic时代，我的稀缺价值是什么？- 能设计复杂系统的人（Agent Orchestrator）- 能理解博弈论的人（如何激励Agent）- 能做判断和选择的人（AI不能替代的人类直觉）

44. Bash Is All Agent Need：Anthropic 重新定义智能体开发

45. 梦想照进现实！AI大模型全屋智能居然成了?!

46. 用AI手搓西部世界手机版？能一键生成冒险岛的AI，被我体验到了

47. 盘点一周AI大事(2月22日)｜不赚钱拔网线，龙虾狂赚1万工程师开源龙虾打工人ClawWork，10刀开局，7小时狂赚1万刀工程师Sigil开源首个全自主智能体The Automaton Kimi上线云端龙虾Kimi Claw 网易开源桌面版龙虾LobsterAI Google上线地表最强大模型Gemini 3.1 Pro Gemini接入音乐模型 Lyria 3 NotebookLM升级，动动嘴就能修改PPT，还支持导出PPTX格式 Anthropic发布Claude Sonnet 4.6 Claude与Figma官宣史诗联动，Claude Code写的页面能一键导入Figma 阿里开源最强行动智能体 Mobile-Agent-v3.5 字节开源极速生图模型BitDance Tavus发布最强数字人模型Phoenix-4 Taalas研发出革命性AI芯片HC1 #抖音年味新知贺岁 #前沿科技趋势发布月 #AI新星计划 #OpenAI #智能体

48. 转发分享：做出好的学习计划首先得确定时间范围，然后确定学习量，最后再为学习量分配时间，明确这些后才有可能列出一个明确可执行的计划。比如，把数学10个章节分解到每天，每天需要学多少一目了然；把67首古诗文背诵任务分解在每月、每周、每日目标中，这样分下来，每天需要完成几首、每周需要复习几首，一目了然，坚定执行即可。——去年今天存的内容（来源未知），分享给大家做寒假计划用。

49. 阿里千问与“AI Layer”崛起：一场重塑互联网的“操作系统”生态战【硅谷101】

50. 终于不用折腾部署了，用WorkBuddy养个龙虾军团替你干活

51. 盘点一周AI大事(3月22日)｜OpenAI红色警报字节开源AI超级员工DeerFlow 2.0 英伟达开源Agent安全补丁NemoClaw Okara发布AI CMO Junior开源能雇佣的AI员工Junior 清华开源Agent课堂OpenMAIC MiniMax发布最强开源大模型M2.7 Miro开源最强深度研究模型Miro Thinker H1 Unsloth开源AI训练工具Unsloth Studio Google升级AI Studio和Stitch 阿里开源最强影视配音模型Fun-CineForge Google开源最强视频超分模型Spark VSSR 研究员开源最强数字人模型ID-LoRA 研究员开源首个城市级别的世界模型Seoul World Model #前沿科技趋势发布月 #AI新星计划 #AI #AIGC #OpenAI

52. 从能聊天的大模型，到会干活的智能体，AI正迎来全新进化。企业AI落地的机会就藏在这里。#网络名人赞两会 #2026全国两会 #红衣聊AI #产业升级

53. 阿维塔07首发MoLA架构，车载AI也能这么懂你#阿维塔07##阿维塔07华为系MoLA架构首发上车##一句小塔万事对答# 扎克张的微博视频

54. 如果人还需要刻意的去区分Script（脚本）、Skills、Agent，说明 Agent 还不够聪明。理想情况下，任何要求都只需要跟 Agent 说，如果一个要求 Agent 被要求处理很多次，它应该结合历史记忆，主动把这个要求自己整理成 Skills，Script 则是 Skills 的一部分。并且这些 Skills 它是持续更新维护的。所以我现在是什么事都跟 Agent 说，但是我会在执行任务后，引导它去写 Skills 或者更新 Skills

55. Anthropic 发布了一份《2026 Agent 编程趋势报告》，提出了八个预测，核心观点是：写代码这件事正在从"人写"变成"人指挥 AI Agent 写"。网页链接报告有替 Claude Code 打广告的成分，但数据跟我日常用编程 Agent 的体感比较吻合，可以拿来看看 2026 年开发者的工作正在怎么变。【前言：从辅助到协作】报告开头回顾了 2025 年的变化：编程 Agent（Coding Agent）从实验性工具变成了真正能交付功能的生产系统。工程团队发现，AI 已经能处理完整的开发工作流，包括写测试、调 bug、生成文档、在复杂代码库里导航。预测 2026 年这种变化将不再局限于工具的小修小补，而是会引发一场质变：1）单打独斗变团队作战：原本单一的智能体，将进化为协同工作的"智能体团队"。2）效率飞跃：以前需要耗费数小时甚至数天的任务，现在只需极少的人工干预就能完成。3）角色转变：几年前还在逐行写代码的工程师们，将转型为指挥官。他们将通过编排长期运行的智能体系统来处理实现细节，从而腾出手来专注于架构和战略。这场变革的核心是"协作"。虽然开发者在 60% 的工作中都会用到 AI，但真正能"完全甩手"交给 AI 的任务只有 0-20%。这说明，AI 更像是一个时刻在线的合作伙伴。要用好它，你需要精心设置、巧妙提示（Prompting）、主动监督，并运用人类的判断力，尤其是在那些高风险的工作中。这份报告梳理了 2026 年将定义智能体编程（Agentic Coding）的八大趋势。这些预测分为三类：1）重塑开发方式的基础趋势 2）扩展 AI 能力的能力趋势 3）以及影响业务成果的影响趋势。用过 Claude Code 或 Cursor 的人应该都有体感：AI 确实能帮你省很多事，但你不能撒手不管。它更像一个能力很强但需要你带方向的队友，不是一个可以完全信任的外包。软件开发正在向这样一个模式进化：人类专家专注于定义"什么问题值得解决"，而 AI 负责处理"如何实现"的战术工作。【第一部分：基础趋势】【趋势 1：软件开发生命周期发生巨变】报告认为，这是自图形用户界面（GUI）诞生以来，人机交互最大的一次变革。!(imgs/software-development-life-cycle.png)回顾一下历史：从机器码到汇编，再到 C 语言和现代高级语言，每一次抽象层级的提升，都在缩小人类思维和机器执行之间的距离。2025 年，AI 改变了代码的编写方式；2026 年，这种转变将重塑整个开发流程和工程师角色。传统的软件开发生命周期（需求 → 设计 → 编码 → 测试 → 部署 → 审查）通常以"周"或"月"为单位。在 Agent 介入后，这些阶段还在，但周期被极度压缩到"小时"甚至"天"。Agent 负责实现代码、自动化测试和文档生成，监控反馈直接推动快速迭代。报告做了三个预测：第一，写代码、调试、维护这类"苦活累活"将主要交给 AI，工程师们把精力放在架构设计、系统设计这些更高层级的工作上。第二，工程师的角色从"写代码的人"变成"编排 Agent 写代码的人"。你要做的是评估 Agent 的产出，给方向，确保系统解决了正确的问题。第三，新员工入职一个陌生代码库的时间从几周缩短到几小时。这直接改变了公司对人才调配的思考方式。角色转变这一点我是有共鸣的。我自己用 Claude Code 的体验是：以前一个功能从想到做完，大部分时间花在写代码上；现在大部分时间花在想清楚要什么、怎么拆任务、怎么验收上。编码本身反而变成了最快的环节。报告还提到一个有意思的观察：Agent 接手实现工作后，工程师并没有被取代，反而变得更像"全栈工程师"。因为 AI 填补了知识空白，你现在可以跨前端、后端、数据库和基础设施工作，不再局限于自己最擅长的那一小块。以前需要跨团队协调数周的事情，现在几次专注的工作会话就能搞定。工程师们更倾向于把那些容易验证、定义清晰或重复性的任务交给 AI，而把高层设计和需要"品味"的决策留给自己。报告引用了一个案例：初创公司 Augment Code 用 Claude 帮工程师快速熟悉复杂的网络平台和数据库代码。某企业客户的 CTO 原本估计 4 到 8 个月才能完成的项目，用了 Augment Code 之后两周就搞定了。【第二部分：能力趋势】【趋势 2：从单个 Agent 进化为协同战队】目前大多数人用 Agent 的方式是：一个对话窗口，一个 Agent，线性处理任务。报告预测 2026 年会出现多 Agent 协同工作的模式，处理复杂度远超单个 Agent 能力上限的任务。具体来说，是一种多 Agent 层级架构：一个"指挥官 Agent"负责拆解任务、分配工作、合成结果、把控质量；下面挂着多个"专家 Agent"，分别负责架构设计、代码实现、测试验证、审查文档。这种并行处理的好处不只是快，还能通过不同视角发现盲点。不过这需要新技能：任务拆解、Agent 专业化和协调协议，以及能显示多个并发 Agent 会话状态的开发环境。!(imgs/coding-agent-architectures.png)劳动力管理平台 Fountain 的案例很有说服力：他们用 Claude 构建了分层多 Agent 系统，一个"Copilot"作为指挥官，协调负责筛选候选人、生成文档和情感分析的子 Agent。结果是筛选速度提升 50%，入职速度提升 40%，候选人转化率翻倍。某物流客户原本需要一周多才能招满一个新运营中心的人，现在不到 72 小时。我觉得多 Agent 协同是 2026 年最值得关注的方向之一。单个 Agent 的上下文窗口（context window）有限，能处理的复杂度也有天花板。把任务拆分给多个 Agent 并行处理，再合成结果，理论上能突破这个瓶颈。【趋势 3：长时间运行的 Agent 构建完整系统】早期 Agent 只能处理几分钟内搞定的小任务：修个 bug、写个函数。到 2025 年底，已经能花几个小时生成完整的功能集。报告预测 2026 年，Agent 将能连续工作数天，在极少人工干预下构建整个应用和系统。三个预测：1）Agent 的任务时限从分钟级扩展到天或周。它们将能自主规划、迭代，从失败中恢复，在复杂项目中保持状态一致。2）技术债务清理。那些因为没时间处理而积压多年的技术债（为了短期速度而牺牲代码质量，后续必须还的"债"），现在可以交给 Agent 系统性地消除。3）创业加速。创业者可以在几天内将想法转化为已部署的应用。乐天（Rakuten）的案例让人印象深刻：工程师让 Claude Code 在 vLLM 这个 1250 万行代码的大型开源库中实现一种特定的向量提取方法。Claude Code 自主工作了 7 个小时，一次运行就完成了全部工作，数值准确率达到参考方法的 99.9%。这个案例的价值在于它展示了 Agent 在真实的大型代码库中长时间自主工作的能力。1250 万行代码，7 小时自主运行，99.9% 准确率，这在一年前是不可想象的。技术债清理这一点对很多团队来说可能最有实际意义。谁的代码库里没有一堆"早就该重构但一直没人动"的东西？以前没人愿意碰是因为投入产出比太低，现在交给 Agent 去做，成本大幅降低。【趋势 4：人类监督通过智能协作实现规模化】2026 年最有价值的能力进步，也许是 Agent 学会了什么时候该求助。这不是要把人类踢出局，而是让人的注意力花在刀刃上。三个预测：1）Agent 质量控制标准化。组织用 AI Agent 来审查大规模的 AI 生成代码，分析安全漏洞和架构一致性。这个工作量靠人工是不可能覆盖的。2）Agent 学会"举手提问"。聪明的 Agent 不会盲目尝试所有事情，它们会识别出需要人类判断的情况，标记不确定性，把有潜在商业影响的决策交给人类。3）从"全盘审查"到"重点审查"。人类不再需要盯着每一行代码，而是处理那些真正新颖的、边界案例和战略决策。报告提到了一个有趣的"协作悖论"：虽然 AI 承担了大量工作，但工程师能"完全放权"的部分却很少。原因是越到概念复杂或依赖设计的任务，工程师越倾向于自己掌控或跟 AI 紧密协作，而不是完全甩手。一位 Anthropic 工程师说得很到位："我主要在我知道答案应该是什么样子的情况下使用 AI。这种判断力是我通过'笨办法'做软件工程积累出来的。"这句话点出了一个容易被忽略的事实：你越有经验，越能从 AI 协作中获益。因为你知道什么是好的、什么是对的，才能有效地指导和验收 Agent 的工作。AI 放大的是你已有的能力，而不是凭空创造能力。印度金融科技平台 CRED 的案例也印证了这一点：他们在整个开发生命周期中使用了 Claude Code，执行速度翻倍。但这不是通过取消人类参与实现的，而是把开发者从低价值工作中解放出来，转向更高价值的工作。【趋势 5：Agent 编程扩展到新领域和新用户】2026 年，编程不再是专业软件工程师的专利。三个预测：1）语言障碍消失。支持范围扩展到 COBOL、Fortran 等冷门或遗留语言，维护老旧系统不再是噩梦。2）编程民主化。网络安全、运营、设计和数据科学领域的非传统开发人员，通过新界面使用 Agent 编程。Anthropic 自己推出的 Cowork 就是面向非开发者的文件和任务管理自动化工具。3）人人都更"全栈"。安全团队用它分析陌生代码，研究团队用它构建前端可视化，非技术员工用它调试网络问题或做数据分析。"会写代码的人"和"不会写代码的人"之间的界限正在变模糊。法律科技平台 Legora 的案例：他们利用 Claude 的指令遵循能力，让不懂编程的律师也能创建复杂的自动化工作流，不需要工程团队介入。这个趋势我在身边已经看到了。越来越多的产品经理、设计师、运营人员开始用 Cursor 或 Claude Code 做一些简单的工具和自动化脚本。以前这些需求要么排队等开发排期，要么就一直搁置。现在他们自己就能搞定，虽然不够精致，但能用就行。【第三部分：影响趋势】【趋势 6：生产力收益重塑软件开发经济学】报告提出了一个"三大乘数效应"：Agent 能力提升、编排方式改进、人类经验更好地发挥，这三者叠加产生的是阶跃式提升，而不是线性增长。因为开发周期从周变天，很多以前觉得"不划算"的项目现在变得可行了。Anthropic 内部研究发现了一个有意思的模式：工程师报告说每个任务的花费时间减少了，但产出量的增加幅度更大。也就是说，AI 带来的生产力提升主要体现在产出量上，发布更多功能、修更多 bug、做更多实验，而不仅仅是做同样的事更快。其中大约 27% 的 AI 辅助工作，是那些如果没有 AI 就根本不会做的事情：扩展项目、做个交互式仪表盘之类的"有了更好但没有也行"的工具、试探性的实验。工程师还报告说会顺手修更多"小毛病"（papercuts），那些以前优先级太低不值得专门花时间但又影响体验的问题。通信巨头 TELUS 创建了超过 13000 个定制 AI 解决方案，工程代码发布速度提升 30%，累计节省超过 50 万小时。27% 这个数字很有意思。它意味着 AI 不只是帮你更快地做原来的事，还让你能做以前根本不会去做的事。这才是真正的生产力释放。【趋势 7：非技术用例在组织内扩展】销售、市场、法律和运营团队开始用 Agent 编程解决自己的问题。最了解业务痛点的专家不再需要排队等 IT 部门排期，他们可以直接构建解决方案。那些不值得占用工程师时间的边缘问题得到解决，手动流程被自动化。Anthropic 自己的法律团队就是个例子：他们用 Claude 构建了自动化合同修订和内容审查的工作流，把营销审查周期从 2-3 天缩短到 24 小时。一位没有编程经验的律师构建了自助工具，在问题进入律师队列前就进行分流。Zapier 更夸张，整个公司 89% 的员工都在用 AI，内部部署了 800 多个 AI Agent。设计团队用 Claude 在客户访谈中实时生成设计原型，以前需要几周才能出的东西，现在当场就能看到。【趋势 8：安全的双刃剑】Agent 编程在强化安全防御的同时，也可能被攻击者利用。好的一面：有了 AI 辅助，任何工程师都能进行深度安全审查和系统加固，相当于人人都有了安全专家级别的能力。坏的一面：攻击者也会利用 Agent 扩大攻击规模。为了应对机器速度的攻击，自动化的 Agent 防御系统将变得必要，实现毫秒级的检测和响应。报告的建议是：安全架构必须在设计之初就嵌入，而不是事后补丁。提前做好准备的团队，在面对使用同样技术的攻击者时会有优势。【最后】这份报告读下来，最核心的一点是：AI 不是来取代开发者的，而是在改变开发者做什么。以前 80% 的时间花在实现上，20% 花在思考上；现在反过来了。你需要花更多时间想清楚要做什么、怎么拆解、怎么验收，然后把实现交给 Agent。对个人来说，最值得投资的能力是：系统设计能力、任务拆解能力、以及评估代码质量的眼光。这些"老功夫"在 Agent 时代反而更值钱了。对团队来说，2026 年谁先把 Agent 编程从"个人工具"变成"组织能力"，谁就能拉开差距。那些还在观望的，会发现游戏规则已经变了。

56. Agency Agents：号称能一键搭建一个“AI公司”，配备55个高度专业化的AI员工，涵盖了工程、设计、营销、产品、项目管理、测试、支持、空间计算等多个部门，非常像现实中的公司架构。项目亮点：- 明确分工，每个AI都是某个领域的大咖，比如前端工程师、品牌守护者、增长黑客、Sprint优先级规划师、质量验证专家等；- 强调协作和流程，模拟真实团队工作，解决单一大模型扛全的性能瓶颈和职责模糊问题；- 支持Claude Code等主流AI代码工具，且自带批量生成和安装脚本，方便集成到各种AI开发环境。社区反馈和潜在问题：- 很多网友表示这套系统在“演出”层面非常完整和有趣，但实质执行时仍然有上下文共享难题，多个agent之间的记忆和协调尚不可控；- 多agent间消息传递带来海量tokens消耗，成本和效率成了大考验；- 也有人提出可以配合类似GSD，Paperclip等工具做更好地执行管理和成本控制；- 有人建议加入一个“成本管控agent”，专门监控预算和token消耗，避免“爆账”。未来展望：这类多agent“AI公司”架构是2025年后业界的新趋势，有论文表明多agent协作能提升复杂任务完成率25%左右，远优于单agent模型。尽管目前还处于早期，可玩性和探索价值极高。正如Greg所说，未来属于愿意折腾这些新技术的创造者。想玩转AI多agent团队，又想少踩坑的话，这个项目值得关注和研究。源码开放，社区活跃，非常适合爱折腾的工程师和创始人们自己动手搭建“未来的公司”。#AI创造营##人工智能# GitHub：github.com/msitarzewski/agency-agents

57. ClawTeam：让 AI Agent 自主组建团队、分配任务、协同工作的 CLI 工具github.com/HKUDS/ClawTeam/港大开源的一个项目：“AI 编程 Agent 很强大 —— 但它们各自为战。当任务太大时，你只能手动拆分工作、复制粘贴上下文、合并结果。如果 Agent 能自己组队呢？ClawTeam 实现了 Agent 群体智能（Swarm Intelligence）—— Agent 自主组建团队、分工协作、共享发现、收敛到最优方案。一个 Leader Agent 可以： 🚀 创建子 Agent —— 每个子 Agent 拥有独立的 Git Worktree 和 tmux 会话 📋 分配任务 —— 支持依赖链，完成时自动解除下游阻塞 💬 发送消息 —— 向任意子 Agent 发送指令 📊 监控进度 —— 查看看板、读取实验结果 🔄 调整方向 —— 终止低效 Agent，用新方向重新分配人类只需提供初始目标，群体智能完成剩下的一切。”#How I AI#

58. 昨天“我觉得 AI 不但不会让架构师变多，反而可能会让架构师更加稀缺” 网页链接的观点下面，有人留言说：“不是让你自己成为编程架构师，而是你要让AI成为编程架构师”对于这样的观点我是不认同的，AI 未来也许能成为编程架构师，但这套路径还很遥远，和 AGI 一样遥远：1. 长上下文还没解决好，架构能力需要对系统有全局了解，当前你没办法把整个代码库扔进去也许可以像 DeepSeek OCR 论文那样用缩略图，但那还是理论上2. 对代码结果的反馈 AI 还不能直接感知，架构能力不是理论，更需要实践，架构效果好不好一定是要去实际运行，在运行中收集反馈并调整。现在 AI 根本没法感知系统的运行效果，让它自己去搭个运行环境也许勉强可以，怎么测试并评估系统的反馈是做不到的3. 长期记忆仍然没解决，架构师设计过程中，有大量的沟通工作，和 PM 和程序员，这些沟通的内容都要融合到架构中，但怎么把它们记下来并融入架构设计，并在设计后验证这些记忆中的内容，都是挑战。4. AI 对多个 Agent 的组织能力还有待提升，架构师不仅仅是一个技术工作，不是写个架构设计文档就结束了，还需要去传播架构知识，基于架构去调整组织结构，基于组织结构去整合结果，这方面至少要 AI 进化到组织者这个阶段另外我这些观点也只是针对当前，也许未来五到十年会有变化，将来如果我错了我也很乐意修正自己观点，比如去年我还觉得 Coding Agent 不靠谱，而现在我觉得“真香”。

59. 2026年AI全景预测：迈向百亿智能体时代的20个发展趋势。 #大咖观察 #人工智能 #红衣聊AI #智能体 #AI时代

60. 【原神】海精灵们的礼物/那维莱特/原神月之四/枫丹世界任务

61. 2025过去了！这一年你是不是也在为AI焦虑？老周用360一整年的实践，告诉你答案：不用怕，抓住Agent就赢了！从我自己敲代码做100多个智能体，到带领团队All in，这条AI布道之路，全是实战干货。 2026，你想和智能体一起搞定啥？评论区留言，老周帮你研究！#大咖观察#2026 #年度总结 #红衣聊AI #agent

62. 探访云栖（二）：AI Agent元年，谁在打造“数字员工”？【101 Weekly】

63. 华为新品发布会来了！这次折叠旗舰带来了颠覆性体验——小艺智能体首次实现商用A2A智能体协作！#华为折叠屏首发A2A智能体协作#通过Agent to Agent协议，小艺能和伙伴们协同处理工作生活需求，只需一句话指令，它就能联动多个智能体高效协同，处理工作生活需求简直一键到位。这次发布会着实让人大开眼界，个性化服务简直贴心到爆，折叠体验真的跨入新阶段。我已经迫不及待想上手体验了，华为这次对智慧生活的诠释又刷新了我的认知！新品必火！

64. #苹果AI团队持续失血#苹果Apple Intelligence都发布快2年了，目前还是没有看到有什么质提升。无论是海外还是国内的AI都没一个很好的AI大模型落地。前段时间就爆料国行苹果设备会接入阿里的通义千问AI大模型，但一直没见具体落地。海外苹果设备从当初用ChatGPT辅助，最近又传苹果会全面改用Google Gemini的AI大模型。反正苹果的AI还不知道需要多久才能真正用起来。

65. Agent Skills 终极指南：入门、精通、预测网页链接“应该是全网最好的 Skills 中文指南与教程，全文 1.2w 字，包含了我对 Skills 的完整应用思考。巧借通用 Agent 内核，只靠 Skills 设计，就能低成本创造具有通用 AI 智能上限的垂直 Agent 应用。”内容包含： 1.最容易读懂的 Skills 概念与原理介绍 2.讨论 Skills 的真实价值、技术优势、对 AI 产品设计的影响 3.非常完整的 Skills 使用与开发教程 4.Skills 的场景识别，什么时候适合开发、使用 Skills？#AI创造营##科技先锋官#

66. 为什么鸿蒙座舱5可以把交代的事办得干净利落？看完MoLA智能化架构后我懂了

67. Manus被Meta收购，这是中国AI路线的一次胜利。 #大咖观察 #红衣聊AI #manus #Meta #agent

68. 给建议的AI看够了？MiniMax Agent 让AI直接住进你的电脑干活#AI新星计划#科技改变生活#MiniMAX#Agent#minimaxagent

69. Agent Infra到底是什么？【AI基建】

70. Context 还不够，Harness 才是 Agent 工程优化的正解？

71. 今天我们开源了一个新的AI Agent项目。Wegent：一个能够定义、编排和执行Agent团队的开源系统。和其它Agent开发系统的区别是，Wegent底层使用声明式方式构建和编排 AI Agent，这就意味着部署智能体就像是在K8S里部署负载一样，可以实现基于yaml直接定义部署Agent服务。同时，Wegent的底层定义中区分了智能体的“Ghost（提示词）”和“Shell（执行器）”的概念。例如，你既可以把Claude Code作为智能体的“壳”实现远程编码Agent系统，也可以基于Agno的“壳”来实现DeepResearch系统。在开源项目里也增加了配套的前端服务，可以直接在网页中构建新的Agent团队。项目地址：github.com/wecode-ai/Wegent（附件是用Wegent实现的网页版Claude Code的效果）

72. 27岁清华学霸姚顺雨掌舵腾讯AI 27岁清华学霸姚顺雨掌舵腾讯AI，一个98年出生的年轻人，从清华姚班到 OpenAl，再到腾讯首席AI科学家，顶级人才回流，AI竞赛正式进入agent时代！#AI #腾讯 #agent

73. 手把手彻底学会 Agent Skills！【小白教程】

74. 你以为你看到的是AI的想法，实际上你看到的是：人类行为模式的一次完整数字回放。#大咖观察 #红衣聊AI #人工智能技术 #agent #AGI

75. 2025年，Agent对于打工人真的有用吗？实测OK Computer

76. 对话云栖大会：下一个AI爆款、大模型进化与Agent万亿级企业市场

77. Anthropic发布万字长文：系统化评估 AI Agents 的工程方法

78. Agent Skill 相关资料、笔记和思考

79. openclaw三省六部-对外支援

80. Day116 管好15个AI员工的5个关键设定,三省六部架构给我的启发

81. Edict:三省六部 AI 多 Agent 协作

82. 小龙虾三省六部

83. 开源项目--1300 年前的唐朝制度，吊打了我用过的所有 AI 框架

84. 还在部署OpenClaw？有人开始用AI当“赛博皇帝”了

85. 我用唐朝的三省六部制,重新设计了 AI 多 Agent 协作架构——然后 CrewAI 和 AutoGen 在我眼里都不香了

86. 告别混乱协作！把AI Agent放进“三省六部”，效率直接起还在为AI多Agent协作混乱、不可控头疼？试试用中国千年帝国的“三省六部”制度来重构协作逻辑！这套名为Edict的框架，把AI Agent分工成： - 中书省：负责规划与任务分解 - 门下省：专职审核，可直接封驳打回 - 尚书省：统领六部并行执行 - 军机处：实时看板，让你像“皇上”一样掌控全局对比传统框架（CrewAI/AutoGen），它有三大核心优势： ✅ 制度性审核与分权制衡 ✅ 极致的可视化与可干预（叫停/取销/恢复） ✅ 零核级部署与模型热切换让AI协作从“自由创作”变成“精密运转的帝国机器”，可控、高效、可追溯。 #AI多Agent #多智能体协作 #三省六部AI #Edict框架 #AI工程化

87. openclaw github高星项目：用古代官制设计的 AI Agent 协作架构

88. 我用AI搭建了一个三省六部管理系统

89. Multi-Agent 架构深度剖析：Anthropic Workflows vs OpenAI Agent Teams

90. OpenClaw之外的新方向：AI多Agent架构创新 — 三省六部·Edict项目解析 - 哔哩哔哩

91. 把老祖宗的智慧用在 AI 身上——三省六部制

92. 我用三省六部架构训练9只AI龙虾团队（openclaw）很多人不知道，中国古代的三省六部其实是一套极其先进的“组织架构系统”。我把这套体系搬进了 AI。用 OpenClaw（龙虾）训练了 9 个专业化 Agent： 👑 龙虾皇帝：负责最终决策 📜 尚书省龙虾：负责执行任务 🔍 门下省龙虾：负责审核与纠错再加上完整的问责 + 审计机制。结果就是—— 一个可以自动决策、自动执行、自动审计的 AI 团队。这套系统跑起来，比很多人类团队还要严密。如果你想：本地部署 OpenClaw 搭建 AI Agent 团队或升级调试你的系统可以联系我。#openclaw #股票 #厦门 #DeepSeek部署#clawdbot

93. 从模块到良好：如何设计一个生产级的Agent架构？

94. 人人都是赛博皇帝：OpenClaw 用三省六部重构多 Agent，AI 也开始分权制衡

95. 【演绎核】与【概率壳】：AI Agent 工程架构优化

96. 谁才是多Agent真大哥？海外多Agent框架 OpenClaw ，遇上中式三省六部，到底谁更好用？ 🦞 OpenClaw：国际多Agent框架 ◦ 流程调度+插件生态 ◦ 高效灵活，适合快速迭代 🫅三省六部 ◦ 中式AI协作逻辑 ◦ 中书省：规划决策 ◦ 门下省：审核封驳 ◦ 尚书省：统筹执行 ◦ 六部：专业分工一套严谨到离谱的古代官场协作逻辑这场中外AI思路的正面碰撞你站谁？#AI #OpenClaw #Agent #龙虾#三省六部

97. 三省六部AI多Agent协作框架edict推荐

98. Agent Team 实践与架构设计：在约束下构建可演进的一个人开发团队

99. 从一次性指令到可复用资产：AI Agent 的 Skills 架构如何重塑开发范式？

100. 赛博朝廷：三省六部 AI 多 Agent 协作架构

101. 从“任务执行”到“工程组织”：AI软件工程能力的三层结构

102. 智能体｜Agent 架构演进与选型

103. 【AI + 软件工程革命】9、多 Agent 系统：AI 团队是如何协作的

104. 2026年还不会multi-agent开发? 这8个谷歌官方multi-agent设计模式你收好

105. Agent 工具执行安全框架：企业级 Agent 的"最后一公里"

106. 解锁多agent大模型推理的力量

107. 多Agent来了，AI产品经理的底层逻辑要换了

108. 微软Agent Framework深度解析：优于AutoGen的多智能体新开源框架

109. 实测 MGX｜让一群Agent联手coding，比“模型即agent” 更接近AGI？

110. Agent专题

111. 别再弄玩具级Demo了！这本AI Agent架构神了

112. AI Agent核心概念与架构详解：十分钟速成Agent、A2A、MCP和Skills概念全解析！

113. 一文搞定6 种流行的 Agent 式设计模式！

114. 为了让Agent理解上下文，这个团队选择自己重写架构

三省六部Agent架构，是制度创新还是工程表演？

精选参考来源