Search: #AI应用架构

  1. 《生成式 UI:是什么、如何工作、何时使用》

    《生成式 UI:是什么、如何工作、何时使用》

    标签:
    #AI应用架构 #UX设计
    #生成式UI #LLM前端集成 #声明式界面生成 #AGUI协议 #组件库组合 #数据可视化仪表盘

    总结:
    这是一篇务实的生成式 UI(Generative UI)入门文章。作者团队基于两周的概念验证实践,拆解了这一架构的定义、三种实现层级、完整的数据流转管道,以及收益与代价,并用两个可运行的 demo 说明它在开放式数据分析场景中的价值——核心结论是:AI 负责“设计回答问题的界面”,而非只给出文字答案;生产环境中应采用“声明式”路线(AI 配置预建组件,而非自由写代码),并且生成式 UI 是传统界面的补充而非替代。

    文章要点:
    1. 生成式 UI 是全栈架构:后端调用 LLM 决定“展示什么、怎么展示”,前端负责渲染组件和处理交互,界面从“静态且人人相同”变成“动态且千人千面”。
    2. 实现分三个层级:静态式(AI 从固定库里选屏)、声明式(AI 组装 JSON 组件树,生产环境主流)、开放式(AI 从零生成代码,风险最高)。
    3. 工作流程是一条清晰管道:用户提问 → LLM 分析并调用工具拉数据 → 生成描述界面与数据的结构化 schema → 经 AG-UI 协议同步到前端 → 前端把 schema 渲染成真实组件。
    4. 收益是真实个性化、可扩展的灵活性(少量组件组合出上千种界面)、开发提速;代价是延迟、Token 成本、布局不可预测(用户难以形成肌肉记忆)以及数据隐私问题——都有已知的缓解手段。
    5. 两个 demo 验证价值:虚构电商“聊天提问 + 画布渲染”的仪表盘,以及内部工时工具的生成式报表层——后者证明少量代码即可应对几乎无限的临时查询,且 AI 不确定时会主动追问而非臆测。
    6. 适用边界明确:稳定重复的流程(比如结账按钮)仍应使用标准 UI,生成式 UI 赢在“流程复杂、问题不可预测”的场景。
    7. 它对设计工作提出新要求:设计系统不再只定义组件,还要定义语义规则——AI 遇到不确定性如何反应、意图与界面的匹配规则、以及保障生成界面安全可用的护栏。

    URL:https://www.kzsoftworks.com/blog/generative-ui-101

  2. 《Paperclip:用开源“公司”编排 AI 智能体团队》

    《Paperclip:用开源“公司”编排 AI 智能体团队》

    标签:
    #AI_Agent编排 #Agentic任务管理 #组织治理与成本控制 #多智能体协作 #开源自托管 #Nodejs与React #OrgChart #Heartbeat调度 #预算管控 #多组织隔离

    总结:

    Paperclip 是一个开源的自托管应用,用“经营公司”的方式管理 AI 智能体团队:它把目标、组织架构、任务、预算、审批、审计和运行环境整合进一个控制台。你可以接入 Claude Code、Codex、Cursor、OpenClaw 等任意 Agent,让它们像员工一样有角色、汇报线、预算与心跳调度,并在一个看板里追踪进度与成本。

    文章要点:
    1. 核心定位是“管公司,不是管聊天”:Paperclip 不造 Agent、不做拖拽式工作流,而是把多个 Agent 编排成有目标、有层级、有治理的组织。
    2. 使用路径很直接:先定义商业目标,再“招聘”不同职能的 Agent(CEO/CTO/工程/设计/营销等),最后审批策略、设置预算并启动运行。
    3. 四大支柱覆盖日常到平台层:Agentic 任务管理、Agent 组织架构、Agent 员工培训、Agentic OS(运行基础设施)。
    4. 任务系统强调可审计与防冲突:任务带公司/项目/目标链路,支持原子领取、执行锁、阻塞依赖、评论、附件与产出物。
    5. Heartbeat 让 Agent 按计划醒来干活:支持定时唤醒、事件触发、上下文续接、结构化日志与自动恢复,减少人工盯梢。
    6. 成本控制是硬约束:按公司/Agent/项目/目标/模型等维度追踪 token 与费用,预算到线会告警并硬停止,避免“跑飞”。
    7. 治理与回滚机制完整:审批流、执行策略、决策记录、暂停/终止 Agent、配置版本化与审计日志都在系统内完成。
    8. 支持多组织隔离与可移植性:一套部署可跑多家“公司”,数据完全隔离;还能导出/导入组织配置并做密钥清理。
    9. 运行环境面向真实开发流程:支持项目工作区、隔离执行工作区(如 git worktree)、开发服务/预览链接、密钥注入与技能加载。
    10. 它不是聊天机器人、不是 Agent 框架、不是代码评审工具,而是面向“多 Agent 团队”的编排控制平面。

    URL:
    https://github.com/paperclipai/paperclip

  3. 《框架还重要吗?》

    《框架还重要吗?》

    标签:
    #编程 #Web开发 #AI编程 #前端框架 #React #软件工程 #技术趋势 #VibeCoding

    总结:

    这是一篇探讨在 AI 编程时代 Web 框架是否仍然重要的深度分析文章。作者 Brooks Lybrand 作为拥有三年开源框架开发经验的前端工程师,针对"模型已经足够好,框架选择不再重要"的流行观点进行了系统性反驳,论证了框架在提供抽象、结构和约束方面的核心价值,并呼吁行业继续创新和构建新框架。

    文章要点:

    1. **对"React 已赢"论的质疑**:作者指出当前流行观点认为由于 LLM 训练数据中 React 代码最多,模型最熟悉 React,因此无需尝试其他框架。但他认为这种逻辑存在矛盾——如果框架真的不重要,那连 React 都不需要,直接用 Web Components 或让 AI 生成原生代码即可。

    2. **框架的本质价值**:作者将框架的价值精炼为三点:**提供抽象(Abstractions)、结构(Structure)和约束(Constraints)**。这些价值不仅适用于人类开发者,对 AI 编程同样关键——良好的抽象能避免 AI 重复造轮子或创建混乱的临时方案;清晰的结构帮助 AI 生成可维护的代码;明确的约束(如类型检查、测试)能防止 AI 在迭代中破坏系统。

    3. **AI 时代框架的隐性存在**:引用 React 核心团队成员 Ricky Hanlon 的观点"你要么使用框架,要么构建框架",作者强调即使不显式选择框架,AI 在生成代码时也会隐式地创建框架。与其让 AI 生成一个缺乏维护、充满临时补丁的"隐性框架",不如使用经过实战检验、文档完善的开源框架。

    4. **开发者体验(DX)的重构**:通过分析 HMR(热模块替换)、TypeScript 和 useEffect 等具体技术,作者说明某些传统 DX 功能对人类开发者的价值正在转变,但对 AI 编程仍至关重要。例如 TypeScript 的类型约束能有效防止 AI 在复杂应用中引入错误,而 useEffect 这类强大但易误用的抽象则应该避免让 AI 随意使用。

    5. **框架战争的终结与新机遇**:作者认为 2013-2024 年的"框架战争"已经结束,人们不再渴望为框架争论,但这不意味着框架不再重要。他指出当前框架领域仍存在明显不足,特别是缺乏真正全栈、基于 Web 标准、易于 AI 协作且代码可理解的 JavaScript 框架。

    6. **对未来的呼吁**:尽管承认 AI 正在重塑软件开发,且没人知道其长期影响,作者仍坚持认为认为"所有问题都已解决"是一种颓废的态度。他呼吁继续构建新框架,探索更好的抽象和模式,而不是停留在"现有框架足够好"的舒适区。

    URL:
    https://brookslybrand.com/posts/do-frameworks-matter-anymore/

    > 个人觉得有点片面化,remix 脱离 react 转而用 preact 自创轮子

  4. 《用 AI 定制框架替换 Next.js:一个静态网站的“超个性化”重构实验》

    《用 AI 定制框架替换 Next.js:一个静态网站的“超个性化”重构实验》

    标签:
    #Web开发 #前端工程 #AI辅助编程 #NextJs #静态网站 #自定义框架 #性能优化 #Vercel部署

    总结:

    作者 Max Leiter 用 Claude Code(Fable 5 架构、Opus 实现)在约 3 小时内把个人博客从 Next.js 迁移到了一个为站点量身定制的静态构建框架。新方案把全站编译成纯 HTML,按需加载少量 Preact islands,结果页面体积、Lighthouse 分数、构建时间全面大幅优于 Next.js;代价是放弃了框架生态的无数隐性优化,后续维护与安全问题也由自己承担。

    文章要点:

    1. 作者让 AI “按需造一个比 Next.js 更快的专属框架”,核心思路是只保留这个网站真正用到的 Next.js 功能,而不是继续背着整个框架跑。

    2. 新框架本质上是一个构建脚本:读取文章目录,用 React 在服务端渲染每条路由为静态 index.html,再按 Vercel Build Output API 输出,M2 MacBook 上热构建只要约 0.5 秒。

    3. 性能提升非常夸张:首页 JS 从 208 KB 降到 2.3 KB(约 -99%),移动端 LCP 从 2.4 秒降到 1.3 秒,整页重量从 1153 KB 降到 78 KB,Lighthouse 直接冲到 100 分。

    4. 博客文章页同样收益明显:HTML 更小、JS 只剩 2.3 KB,移动端 LCP 从 2.2 秒降到 1.1 秒,页面重量从 405 KB 降到 57 KB,软导航也改成更轻的 partial/prerender 方案。

    5. 交互没有消失,而是改成“islands”模式:桌面窗口管理器和命令面板用 Preact 组件按需水合,命令面板首次按 Cmd+K 才加载,Preact 兼容层只有约 7 KB,比 React 的 52 KB 轻很多。

    6. 构建链路保留原有体验:MDX 仍在构建期用同一套 remark/rehype 插件编译,shiki 在构建时同时输出两套主题的代码高亮,所以切换主题不需要额外 JS。

    7. AI 还写了一个“parity harness”,对旧站 101 条路由做快照,对比 head、正文和代码块,结果抓出了 8 篇未发布文章泄漏进 RSS、以及一张 404 的 OG 图这类真实问题。

    8. 整个实验花费约 669 美元,API 运行 8 小时 27 分,代码新增 20914 行、删除 2022 行,大约用掉 Claude Code 20x 订阅额度的 10%。

    9. 作者认为这种做法的意义在于“只 vendor 你真正需要的东西”:框架被压缩到约 5000 行,人和模型都更容易审查,也能减少供应链攻击面。

    10. 缺点也很直白:Next.js 里成百上千个小优化和边界处理 AI 未必都知道或能复现;没有现成的 agent 工具链集成;安全修复不再自动从上游来;而且网站一旦有问题,bug、安全、功能需求都归你自己管。

    11. 文章还记录了两个浏览器层面的坑:Chrome 的跨文档 view transitions 会因 head 里的外部 module script 静默跳过入场动画,所以 runtime 必须内联;Safari 对 Speculation Rules 的 feature detection 需要同时检查 API 支持和 document.prerendering。

    12. 作者最后判断:未来可能会出现更多“vendoring”和 agentic rewrite,也就是所谓“slop forks”;更激进的猜测是,框架本身可能会消亡,因为框架真正值钱的是沉淀下来的庞大知识,而这些知识未来可能被蒸馏成 skills 或某种新标准。

    URL:
    https://maxleiter.com/blog/thank-u-next thank u, next | Max Leiter

  5. 《TanStack AI 进入 RC 阶段:从 humble chat() 到完整 AI 生态》

    《TanStack AI 进入 RC 阶段:从 humble chat() 到完整 AI 生态》

    标签:
    #前端开发 #AI框架 #TanStack #TypeScript #开源

    总结:

    TanStack AI 正式从早期原型迈入 RC(Release Candidate)阶段,标志着其从一个简单的 LLM 聊天方法,成长为覆盖聊天、媒体生成、MCP、沙箱、Agent 编排等全场景的 AI 开发框架。核心设计哲学是"不锁定用户"——在传输层、提供商、前后端技术栈上都保持中立,同时通过极致的类型安全和统一的 API 模式降低学习成本。项目由三人业余时间维护,完全开源,无商业路线图。

    文章要点:

    1. 从小 chat() 到大生态 — 最初只有 4 个提供商和一个自定义协议,如今已支持 24+ 提供商,采用 AG-UI 官方协议(被 20+ Agent 框架跨语言支持),并扩展到媒体生成、MCP、沙箱、Agent Harness 等领域。

    2. 中间件是架构的核心超能力 — 几乎所有高级功能(持久化、沙箱 Agent、内存、遥测)都以中间件形式接入 chat() 方法,Durability 则通过适配器插入流式响应。Lazy Tool Calling 用一个布尔标志就能降低 Token 成本。

    3. 传输层零锁定 — 提供 SSE、WebSocket、HTTP Stream、Cap'n Web 等原生传输原语,客户端通过自定义连接适配器消费流,让你对传输层有端到端的完全控制权。

    4. 一套 API 模式打遍所有模态 — 无论是文本生成、图像生成、视频生成、音频生成、转录还是实时音频,API 结构几乎完全相同。学一次模式,换适配器即可,不用学 20 套不同 API。

    5. 类型安全是 DNA 级别 — 不支持的模型选项、缺少必填属性、把某提供商专属工具传给不支持的模型……统统在编译期报错。目标是让你在再复杂的应用里也能自信上线。

    6. chat() 方法是全能核心 — 支持直接对话 LLM 和沙箱 Agent Harness;内置持久化与 Durability(刷新页面、切换对话后能从断点实时续流);支持 Codex 等 Agent 在远程/本地沙箱中运行;还有 Code Mode(Agent 在 isolate 中写代码并执行,优化性能和成本)。

    7. 媒体生成是一等公民 — 实时音频、TTS、图像/视频/音频/音乐生成、转录等全部稳定可用,覆盖 100+ 模型。支持流式直传客户端或一次性生成,两者切换无缝。

    8. RAG 与记忆 — 通过 Cohere、OpenRouter 等提供商支持嵌入和重排序;支持所有主流厂商的 Agent 记忆,让 Agent 跨对话记住用户偏好和关键事实。

    9. 沙箱与 Agent Harness 不挑提供商 — 不强制你用 Daytona、E2B 或 Vercel Sandboxes,基础设施随你选。支持 Codex、Claude Code、Grok、OpenCode 等 20+ ACP 兼容 Agent,甚至能自建本地编码 Agent。

    10. MCP 支持带类型生成 — 不仅能连接外部 MCP 服务器,还能通过 CLI 为远程 MCP 暴露的工具生成类型,保持端到端类型安全。支持连接池和生命周期管理。

    11. 持久化与 Durability 是亮点 — 提供存储原语,你只需实现 Store 并通过一致性测试套件验证,接入持久化中间件后,用户一个月后回来也能从断点续聊。Durability 适配器可将流块持久化到内存、Durable Streams 等,用户重连后不会漏掉任何内容——全部配置约 20 行代码。

    12. 未来路线图 — 核心架构已锁定,接下来重点在 Agent 工作流与编排(并行运行、定时任务、复杂工作流协调),以及继续补齐提供商生态。完全开源,无商业 upsell,欢迎社区贡献。

    URL:
    https://tanstack.com/blog/tanstack-ai-rc TanStack AI Enters the RC Phase | TanStack Blog

  6. 《现代工程价值观:AI 时代的效率与品味》

    《现代工程价值观:AI 时代的效率与品味》

    标签:#软件工程 #AI编程 #代码审查 #团队管理 #技术栈 #开发者体验 #工程管理

    总结:
    作者 Christoph Nakazawa(cpojer)分享了他近半年完全依赖 AI 编码代理完成多个项目的实战经验,指出编程已从"手写代码"转向"指挥系统生成代码"。文章提炼了 AI 时代仍至关重要的五大工程价值观:强所有权、品味至上、严格约束与快速反馈、代码库即上下文、掌控技术栈,并强调管理需更技术化。作者用数据证明效率提升 3 倍,认为未来瓶颈不再是写代码,而是判断力与品味。

    文章要点:
    1. **AI 编码已成常态**:作者过去数月多个项目(Vite+、fate、Codiff、Athena Crisis 等)90%-100% 由 AI 编写,代码质量甚至超越手写,且能在几分钟内完成过去数周的工作
    2. **Codex CLI 是最佳搭档**:使用 GPT 5.5 high 配合 Codex CLI,配合"先写失败测试再修复"的策略,能极大提高一次性正确率;多项目并行时建议每个项目独立窗口,利用空间记忆提升效率
    3. **强所有权比代码更重要**:AI 放大了"懂行"与"不懂行"的差距,小团队(2-3 人)+ 清晰边界 + 独立仓库比大团队协作更高效,审查应聚焦对齐而非代码细节争论
    4. **品味是防"垃圾"泛滥的护城河**:AI 能全天候生成大量平庸代码,工程师的核心价值转向判断"什么值得做",团队应花更多时间思考方向而非盲目堆功能
    5. **严格约束 = 速度**:把代码规范、自动化测试、快速验证等"护栏"做得越严,AI 迭代越快(1 分钟 vs 60 分钟的差距);工具必须支持增量检查,避免随代码量增长而变慢
    6. **代码库即唯一上下文**:将设计文档、产品行为、决策记录全部沉淀在仓库内,让 AI 和人类都能快速理解;代码越简洁、越易读,AI 修复和迭代越高效
    7. **自研技术栈重新划算**:过去依赖第三方库是因为手写代码慢,现在 AI 降低了自研成本,掌控核心依赖能避免被外部框架绑架,获得完全的产品体验控制权
    8. **保留选择权(Option Value)**:任何架构改动都应保留未来大幅调整的可能性,AI 虽让重构变快,但把自己逼进死胡同依然难以脱身
    9. **管理必须更技术化**:执行成本降低后,管理者不能只做方向把控,必须保持领域 expertise,能亲自改代码、做技术决策,"技术型管理"(Tech Lead Management)将成为主流
    10. **效率数据惊人**:近 30 天日均提交 770 次、修改 15k 行代码,是两年前的 3 倍;过去手写巅峰一天 1200 行,现在 AI 辅助可达 10 倍且质量更高

    URL:
    https://cpojer.net/posts/modern-engineering-values Modern Engineering Values

  7. 《为AI智能体设计产品:从界面思维到智能体思维》

    《为AI智能体设计产品:从界面思维到智能体思维》

    标签:#AI产品 #MCP #智能体交互设计 #产品架构 #API设计 #Salesforce #Ramp #Notion

    总结:
    本文由Ramp产品负责人Teddy Riker撰写,探讨了AI智能体时代产品设计的范式转变。作者指出,未来80%的软件交互将通过AI智能体完成,产品团队需要从"为用户设计界面"转向"为智能体设计能力"。文章以Ramp、Salesforce、Notion等案例,提出了三大核心设计原则:主动提供成功所需的上下文规范、建立基于工具调用的反馈循环、识别并填补智能体间的上下文缺口。

    文章要点:

    - **交互范式正在翻转**:传统模式是"用户→界面→数据库",而AI时代正在变成"用户→用户智能体→软件智能体→数据库"。界面不会消失,但80%的交互将发生在智能体之间,产品团队需要为"看不见的用户"重新设计。

    - **Salesforce的激进转型**:这家27年的传统软件巨头推出"Headless 360"计划,将平台所有能力暴露为API、MCP工具或CLI命令,承认图形界面CRM的护城河正在被侵蚀,主动拥抱"无界面"未来。

    - **教会智能体如何成功**:Notion的MCP设计是个正面教材——它在工具描述中明确要求智能体先读取Markdown规范再操作,确保格式准确。相比之下,Slack MCP让智能体"自己摸索"格式规则,结果用户反而要花更多时间修正。产品团队应该主动告诉调用方"你需要知道什么才能成功"。

    - **用反馈循环驱动产品迭代**:Ramp通过三个机制解决智能体交互的可观测性难题:要求每次工具调用附带`rationale`参数解释意图、提供独立的反馈提交工具、在特定工具中预埋上下文种子。这些反馈比人类用户更具体、更一致,能直接转化为新功能需求。

    - **填补上下文缺口是核心设计挑战**:在"用户智能体↔️软件智能体"的协作中,双方各自掌握对方没有的信息。优秀的设计不是让智能体去猜技术细节(如GL code),而是让它们交换语义上下文(如"这是客户晚餐还是团队建设"),由各自擅长的那一方完成最终决策。

    - **敷衍智能体支持的产品会被淘汰**:仅仅发布一个MCP服务器、勾上"支持AI"的 checkbox 是不够的。客户最终会流向那些认真打磨智能体体验、真正理解"最后签支票的可能是AI"的产品。

    文章URL:https://baoyu.io/blog/2026-04-24/teddy-riker-2047312986696454584 为 Agent 设计产品

  8. 《OpenAI Agents SDK:轻量级多智能体工作流框架》

    《OpenAI Agents SDK:轻量级多智能体工作流框架》

    标签:#AI #多智能体 #Python #OpenAI #MCP #智能体工作流 #LLM #实时语音 #沙箱环境

    总结:
    OpenAI Agents SDK 是一个轻量但功能强大的 Python 框架,用于构建多智能体工作流。它支持 OpenAI 的 Responses 和 Chat Completions API,同时兼容 100 多种其他 LLM,具有供应商无关性。框架围绕"智能体"这一核心概念展开,每个智能体都配备指令、工具、护栏和交接机制,让复杂任务可以像搭积木一样拆解协作。

    文章要点:
    - 智能体是核心乐高积木:每个智能体都自带"说明书"(指令)、"工具箱"(函数/MCP/托管工具)和"安全护栏"(输入输出校验),还能互相"交接"任务,像团队协作一样分工处理复杂流程
    - 沙箱智能体让AI真正"动手干活":0.14.0 版本新增的 Sandbox Agent 能在容器环境里操作文件系统、运行命令、打补丁,适合需要长时间执行且要保留工作状态的"重体力"任务
    - 人在回路,安全可控:内置了人类介入机制,在关键节点可以暂停流程等人来确认,避免AI"自作主张"搞出大新闻
    - 全链路可观测:自带 Tracing 追踪系统,能可视化查看每个智能体的思考过程、工具调用耗时和 Token 消耗,方便调试和优化
    - 不挑模型,兼容百家:虽然是 OpenAI 出品,但设计上保持中立,支持接入 100+ 种 LLM,包括通过 LiteLLM 等适配层接入国产模型
    - 实时语音也能玩:支持用 gpt-realtime-1.5 构建语音智能体,把实时语音能力也纳入多智能体协作体系

    文章URL:https://github.com/openai/openai-agents-python

  9. 《Claude架构图生成器:AI一键绘制专业系统架构图》

    《Claude架构图生成器:AI一键绘制专业系统架构图》

    标签:#AI工具 #Claude_Skill #架构可视化 #开发效率 #系统架构图

    总结:
    这是一款专为Claude AI设计的Skill工具,让用户只需用自然语言描述系统架构,即可生成精美的暗色系专业架构图。输出为独立的HTML/SVG文件,无需任何设计技能或额外软件,适合快速迭代和团队协作分享。

    文章要点:
    - 零门槛使用:不需要设计基础,用大白话描述系统组件和连接关系,Claude就能帮你画出专业级架构图
    - 多种输入方式:可以让AI分析代码库自动生成描述,也可以自己手写组件列表,还能直接问Claude要典型架构模板
    - 精美视觉风格:采用暗色主题(Slate-950背景),组件按类型着色(前端青色、后端翠绿、数据库紫色、云服务琥珀色),自带网格底纹和JetBrains Mono字体
    - 独立文件输出:生成单个HTML文件,内嵌CSS和SVG,任何浏览器都能直接打开,方便分享、打印或嵌入文档
    - 实时迭代优化:生成后可以继续在对话中要求修改,比如"加上Redis缓存"或"调整布局",Claude会即时更新图表
    - 多平台安装:支持Claude.ai网页版(Pro/Max/Team/Enterprise)、Claude Code CLI、以及Projects知识库三种方式
    - 丰富示例覆盖:内置Web应用(React+Node+PostgreSQL)、AWS无服务器(Lambda+API Gateway)、微服务(K8s+多语言服务)等典型场景模板

    文章URL:https://github.com/Cocoon-AI/architecture-diagram-generator GitHub - Cocoon-AI/architecture-diagram-generator: Generate beautiful dark-themed system architecture diagrams as standalone HTML/SVG…

  10. 《OpenHarness:开源智能体基础设施框架》

    《OpenHarness:开源智能体基础设施框架》

    标签:#AI #Agent #智能体 #开源 #Python #工具调用

    总结:
    OpenHarness是港大数据智能实验室(HKUDS)推出的轻量级开源智能体基础设施框架,仅用Python实现,代码量比Claude Code轻44倍(1.1万行vs 51万行),提供完整的工具调用、技能加载、记忆管理和多智能体协调功能,让开发者快速构建安全可靠的AI Agent应用。

    文章要点:
    - 极简架构设计:相比Claude Code的51万行TypeScript代码,OpenHarness仅用1.1万行Python实现,去除了企业级复杂依赖如遥测和OAuth,专注于核心Harness架构
    - 五大核心模块:包含Agent循环(支持流式工具调用、并行执行、成本追踪)、工具套件(43种工具覆盖文件/Shell/搜索/Web/MCP)、上下文记忆(CLAUDE.md自动注入、MEMORY.md持久化)、权限治理(多级权限模式、交互式审批)、Swarm多智能体协调(子智能体委派、任务管理)
    - 生态兼容性:完全兼容anthropics/skills技能格式和claude-code/plugins插件生态,支持OpenClaw、nanobot、Cursor等CLI工具集成
    - 开箱即用:一条命令oh即可启动,内置114个单元测试和6个E2E测试套件,提供稳定可靠的基础能力

    文章URL:
    https://github.com/HKUDS/OpenHarness GitHub - HKUDS/OpenHarness: "OpenHarness: Open Agent Harness with a Built-in Personal Agent--Ohmo!"

  11. 《Claude技能构建完整指南》

    《Claude技能构建完整指南》

    标签:#AI #Claude #MCP #Agent_Skills #Workflow_Automation #开发工具 #Anthropic

    总结:Anthropic官方发布的Claude技能构建指南,系统介绍了如何通过SKILL.md文件创建可复用的AI工作流。技能采用渐进式披露架构(YAML前置元数据+Markdown指令+引用资源),可与MCP工具集成实现多步骤自动化。文档涵盖规划、测试、分发全流程,提供5种设计模式(顺序工作流、多MCP协调、迭代优化等),并给出量化评估指标(90%触发准确率、零API失败率),目标帮助开发者在15-30分钟内构建生产级AI技能。

    文章要点:
    - 技能定义:包含SKILL.md(必需)、scripts/、references/、assets/的文件夹结构,采用kebab-case命名规范,支持Claude.ai、Claude Code和API三端通用
    - 渐进式披露设计:三级加载机制(YAML元数据→SKILL.md正文→链接资源),最小化token消耗同时保持专业性
    - 三大应用场景:文档/资源创建(如前端设计)、工作流自动化(如项目管理)、MCP增强(如Sentry代码审查),后者将工具访问转化为可靠工作流
    - 成功指标:技能应在90%相关查询中自动触发,单次工作流工具调用次数明确,零失败API调用,用户无需提示下一步操作
    - 核心设计模式:顺序工作流编排、多MCP协调(跨Figma/Linear/Slack等)、迭代优化循环、上下文感知工具选择、领域特定智能(如合规检查)
    - 测试策略:触发测试( obvious/paraphrased/negative cases)、功能测试、性能对比(有无技能时的token消耗和交互轮次差异)
    - 分发方式:GitHub托管+Claude.ai设置上传,支持组织级部署和API程序化调用,定位为MCP的"知识层"(厨房类比:MCP是厨房设备,技能是食谱)
    - 常见陷阱:描述字段过于模糊导致触发失败、包含XML标签的安全限制、README.md与SKILL.md混淆、指令过于冗长导致模型"懒惰"

    https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf