Agent | 面条的草稿箱

Flue：构建下一代 AI Agent 的 TypeScript 架构框架Flue 提出了一个核心公式：Agent = Model + Harness

Mon, 11 May 2026 10:03:02 GMT

Flue：构建下一代 AI Agent 的 TypeScript 架构框架

Flue 提出了一个核心公式：Agent = Model + Harness。它不仅仅是一个简单的 SDK，而是一个专为构建自主 Agent 设计的“可编程治理框架”（Harness），旨在让开发者能够轻松打造像 Claude Code 或 Codex 这样具备规划、环境感知和执行能力的强力工具。

核心特性：

• 高度可编程： 使用 TypeScript 编写 Agent 逻辑，支持定义复杂的技能（Skills）、工作流和多 Session 管理。
• 自带沙箱环境： 提供内置的虚拟沙箱或连接远程沙箱（如 Daytona），让 Agent 安全地执行 Bash 命令、读写文件或运行代码。
• 安全与隐私： 采用精细的权限控制，确保敏感的 API Token 不会被模型或沙箱环境直接接触。
• 跨平台部署： 编写一次逻辑，即可部署为 HTTP 服务，或在 CLI、GitHub Actions、Cloudflare Workers 等多种环境运行。

与其使用通用的成品 AI 工具，Flue 鼓励开发者根据特定的产品需求、数据和工作流，构建完全属于自己的定制化 Agent。

https://flueframework.com/

#AI #Agent #TypeScript #开发工具 #开源项目

Flue

Flue — The Agent Harness Framework

Agent = Model + Harness. Build autonomous agents and powerful AI workflows with Flue's programmable TypeScript harness. Write once, deploy anywhere.

GitAgent：用 Git 仓库定义 AI Agent 的开放标准AI Agent 框架百花齐放，但每个框架都有自己的结构，Agent 定义无法跨平台复用

Wed, 25 Mar 2026 01:48:08 GMT

GitAgent：用 Git 仓库定义 AI Agent 的开放标准

AI Agent 框架百花齐放，但每个框架都有自己的结构，Agent 定义无法跨平台复用。GitAgent 提出了一种框架无关、基于 Git 的 Agent 定义标准——克隆一个仓库，就能获得一个 Agent。

核心理念

• Git 原生：版本控制、分支管理、Diff 比较、协作能力开箱即用
• 框架无关：通过适配器导出到 Claude Code、OpenAI、CrewAI、Cursor 等任意框架
• 合规就绪：内置 FINRA、美联储、SEC 等金融监管合规支持
• 可组合：Agent 之间可以继承、依赖和委托

怎么用？

一个仓库只需两个文件即可成为 Agent：

• agent.yaml：清单文件，定义名称、版本、模型、技能、工具等
• SOUL.md：身份文件，定义人格、沟通风格和价值观

可选添加 RULES.md（硬约束）、DUTIES.md（职责分离）、skills/（技能模块）、workflows/（工作流）等目录，按需扩展。

亮点设计

• 12 种架构模式：包括人类审批（Human-in-the-Loop）、Agent 版本管理、分支部署、Agent Fork 与混用、CI/CD 集成、生命周期钩子等
• 职责分离（SOD）：定义角色权限和冲突矩阵，确保关键流程不被单一 Agent 端到端控制
• SkillsFlow：用 YAML 定义确定性多步工作流，支持步骤依赖和模板数据流
• 11 个导出适配器：覆盖 system-prompt、Claude Code、OpenAI、CrewAI、Cursor、Lyzr 等主流平台

快速开始

npm install -g gitagent
gitagent init --template standard
gitagent validate
gitagent export --format system-prompt

项目目前已获 1.1k Star，MIT 开源协议。

🔗 https://github.com/open-gitagent/gitagent

#AIAgent #GitAgent #开源 #Agent标准化 #框架无关

GitHub

GitHub - open-gitagent/gitagent: A universal git-native AI agent framework. Your agent lives inside a git repo — identity, rules…

A universal git-native AI agent framework. Your agent lives inside a git repo — identity, rules, memory, tools, and skills are all version-controlled files. - open-gitagent/gitagent

keep.md：把收藏夹变成「可被 AI 直接读取」的 Markdown APIkeep.md 主打一个简单但实用的思路：把你在各处保存的链接，统一存成 Markdown，并提供 API + Agent 技能，让它们能随时被你的工作流或智能体当作上下文调用

Tue, 10 Feb 2026 00:46:58 GMT

keep.md：把收藏夹变成「可被 AI 直接读取」的 Markdown API

keep.md 主打一个简单但实用的思路：把你在各处保存的链接，统一存成 Markdown，并提供 API + Agent 技能，让它们能随时被你的工作流或智能体当作上下文调用。

它适合这些场景：

• 你保存了一堆资料链接，希望 AI/Agent 能直接读懂内容并引用
• 你收藏了文档，想让 Agent 辅助写代码、查用法
• 你保留了长线程/讨论，希望 Agent 自动整理成摘要或草稿

工作方式也很直观：你保存链接 → 系统生成 Markdown → 你的 Agent 读取并使用。
目前提供 Chrome 扩展（页面显示仍在等待 Chrome 商店审核），并支持接入多种工具/平台（如 n8n、Claude SDK、各类 Agent 等）。

费用信息：免费档包含 50 条链接，付费计划 $10/月起。

原链接：https://keep.md/

#书签管理 #Markdown #API #AI工具 #Agent工作流

Keep

Keep | Save and search your bookmarks from anywhere

Keep your bookmarks as markdown and search them from the web, the API, or with your personal AI agent.

Tool Search Tool：让大规模工具库“按需加载”当你的系统里有上百甚至上千个工具时，把所有工具定义一次性塞进上下文，会带来两个典型问题：既浪费上下文窗口（50 个工具就可能吃掉 1–2 万 token），也会让模型在 30–50 个工具以上更容易选错工具

Thu, 15 Jan 2026 06:42:34 GMT

Tool Search Tool：让大规模工具库“按需加载”

当你的系统里有上百甚至上千个工具时，把所有工具定义一次性塞进上下文，会带来两个典型问题：既浪费上下文窗口（50 个工具就可能吃掉 1–2 万 token），也会让模型在 30–50 个工具以上更容易选错工具。Tool Search Tool 的思路是：先只暴露“搜索工具的工具”，其余工具标记为延迟加载；模型需要时先搜索，再把最相关的少量工具定义加载进来使用。

核心机制（7 步）

• 请求里先放入工具搜索工具（Regex 或 BM25 版本）+ 少量常用非延迟工具
• 其余工具定义加上 defer_loading: true（不立即进上下文）
• 模型需要更多工具时，先调用 tool search
• 服务端返回 3–5 个最相关的 tool_reference
• 这些引用会被自动展开成完整工具定义
• 模型再从“已发现”的工具里选择并调用
• 这样既省上下文，又保持工具选择准确率

两种搜索方式怎么选

• Regex 版（tool_search_tool_regex_20251119）：查询是 Python 正则，不是自然语言；适合你希望可控匹配（如 get_.*_data、(?i)slack）。限制：模式最长 200 字符。
• BM25 版（tool_search_tool_bm25_20251119）：查询用自然语言；更适合“我想做什么”式的描述。

两种方式都会搜索：工具名、描述、参数名、参数描述。

延迟加载的最佳实践

• 工具搜索工具本身不要设置 defer_loading: true
• 保留 3–5 个最常用工具为非延迟（提升命中与体验）
• 工具命名与描述尽量贴近用户常用说法（提升可检索性）
• 适合场景：工具 >10 个、工具定义 >10K token、工具选择准确率下降、MCP 多服务器（200+ 工具）等
• 不太适合：工具 <10 个且几乎每次都要用、工具定义非常短

响应与错误处理要点

• 响应里会出现 server_tool_use（触发工具搜索）与 tool_search_tool_result（返回引用列表）
• 常见 400 错误：
• 全部工具都 deferred：至少要有 1 个非延迟工具
• 引用的工具缺少定义：tool_reference 指向的工具必须在顶层 tools 里有对应定义（并通常设为 deferred）
• 工具搜索执行期错误（仍返回 200）：如 invalid_pattern、pattern_too_long、too_many_requests、unavailable

与 MCP、缓存、流式的配合

• 可与 MCP toolset 结合：用 default_config.defer_loading 控制 MCP 工具默认延迟加载，并可对特定工具覆盖
• 支持 prompt caching：已发现的工具可在后续轮次复用，不必每次重新搜索
• 流式返回会把搜索调用与结果作为事件发出，便于前端展示“正在搜索/已找到工具”

原文链接：https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool

#工具调用 #Agent开发 #上下文优化 #MCP #API设计

Claude API Docs

Tool search tool

Claude API Documentation

AI SDK 6：从“调用模型”到“构建可复用智能体”Vercel 发布 AI SDK 6，把 TypeScript AI 应用的开发重心从函数式调用（generateText/streamText）进一步推进到可复用、可维护、可观测的 Agent（智能体）体系，并补齐了安全审批、MCP 全能力支持、调试工具等关键环节

Wed, 24 Dec 2025 14:27:58 GMT

AI SDK 6：从“调用模型”到“构建可复用智能体”

Vercel 发布 AI SDK 6，把 TypeScript AI 应用的开发重心从函数式调用（generateText/streamText）进一步推进到可复用、可维护、可观测的 **Agent（智能体）**体系，并补齐了安全审批、MCP 全能力支持、调试工具等关键环节。

这次更新最值得关注的点

• Agents / ToolLoopAgent：用 Agent 抽象把 模型、指令、工具 固化成可复用单元；ToolLoopAgent 提供“模型调用 → 工具执行 → 回填结果 → 继续推理”的生产级循环（默认最多 20 步），同一套定义可在 UI、API、后台任务复用。
• 工具执行审批（Human-in-the-loop）：工具支持 needsApproval，可按输入内容动态决定是否需要人工确认，适合删除文件、支付、修改生产数据等高风险操作。
• 工具能力增强：
• Strict Mode 可按工具粒度开启，避免某个工具 schema 不兼容导致整次请求失败。
• Input Examples 用“正确示例”提升模型生成工具入参的稳定性。
• toModelOutput 将“应用拿到的完整结果”和“发回模型的 token 内容”分离，减少大文本/二进制（截图、图片）带来的上下文浪费。
• MCP（Model Context Protocol）更完整且稳定：新增/完善 OAuth 认证、Resources、Prompts、Elicitation，并在 @ai-sdk/mcp 中以稳定形态提供，便于对接远程 MCP 服务与第一方数据源。
• 工具调用 + 结构化输出：generateText 与 generateObject 能力统一，支持在多步工具链路后直接生成最终结构化结果（通过 Output.* 声明输出形态）。
• DevTools 可观测性：通过中间件记录并可视化每一步的输入输出、工具调用、token 消耗、耗时与原始请求/响应，解决多步 agent 调试“黑盒”问题。
• Reranking（重排序）：新增 rerank，把检索结果按相关性排序，只喂最相关上下文给模型（当前支持 Cohere、Amazon Bedrock、Together.ai）。
• 标准 JSON Schema 生态：支持实现 Standard JSON Schema 接口的任意 schema 库，降低与特定校验库的绑定成本。
• 图像编辑：generateImage 支持带参考图的编辑（如修补/扩展/风格迁移等），不再只限于文生图。
• 更细的返回原因与用量统计：新增 rawFinishReason，并扩展 usage 的输入/输出细分，方便成本优化与兼容不同供应商行为。
• LangChain 适配器重写：更贴合现代 LangChain/LangGraph，支持流式事件转换、工具调用部分输入流等能力。
• 更多 Provider Tools：围绕 Anthropic/OpenAI/Google/xAI 等提供平台特性工具（如代码执行、文件搜索、Web/X 搜索、MCP 工具等）。

升级提示

从 v5 升级到 v6，可先跑官方 codemod：npx @ai-sdk/codemod v6（文中也提供迁移指南链接）。

原文链接：https://vercel.com/blog/ai-sdk-6
#Vercel #AISDK #Agent #MCP #TypeScript

Vercel

AI SDK 6

Introducing agents, tool execution approval, DevTools, full MCP support, reranking, image editing, and more.

MiniMax M2.1 发布：面向真实复杂任务的多语言编程升级MiniMax 发布新一代文本模型 MiniMax M2.1，目标从“可用、低成本”进一步走向“能解决真实世界的复杂任务”，重点补齐多语言工程协作与办公场景执行力

Tue, 23 Dec 2025 13:52:08 GMT

MiniMax M2.1 发布：面向真实复杂任务的多语言编程升级

MiniMax 发布新一代文本模型 MiniMax M2.1，目标从“可用、低成本”进一步走向“能解决真实世界的复杂任务”，重点补齐多语言工程协作与办公场景执行力。

这次重点提升了什么？

• 多语言编程能力系统增强：覆盖 Rust / Java / Go / C++ / Kotlin / Objective‑C / TypeScript / JavaScript 等，更贴近真实项目的多语言栈协作。
• Web & App 开发更强、更好看：强化原生 Android / iOS 开发，同时提升设计理解与审美表达，支持复杂交互、3D 场景模拟与高质量可视化。
• 更适合办公场景的“复合指令”执行：在多约束条件下做端到端任务推进，更强调“按要求完成”而不是只写对代码。
• 更简洁、更高效的输出：相较 M2，响应更精炼、速度更快、token 消耗更低，适配持续式 AI Coding / Agent 工作流。
• 更强的 Agent / 工具泛化：官方称在多种编码工具与 Agent 框架中表现稳定，并兼容常见的上下文管理约定。
• 对话与写作质量同步提升：不仅是“更会写代码”，也更擅长技术文档与日常写作的结构化表达。

基准与展示

• 在多项软件工程评测上相对 M2 有明显提升，并强调多语言场景竞争力；同时引入 VIBE（含 Web/Simulation/Android/iOS/Backend）评测体系，用更接近真实运行环境的方式验证“能跑、能交付”。

如何使用

• API：已上线 MiniMax Open Platform
• 产品：基于 M2.1 的 MiniMax Agent 已开放
• 开源：模型权重提供本地部署，推荐 SGLang / vLLM 等推理框架

原文链接：https://www.minimax.io/news/minimax-m21

#MiniMax #开源大模型 #AI编程 #多语言开发 #Agent工作流

MiniMax

MiniMax M2.1: Significantly Enhanced Multi-Language Programming, Built for Real-World Complex Tasks

GLM-4.7：把“能写代码”推进到“能当搭档”Z.ai 发布 GLM-4.7，主打更强的工程落地能力：不仅写得对，还更擅长在真实工作流里（Agent、终端、工具调用）稳定推进任务

Tue, 23 Dec 2025 01:11:17 GMT

GLM-4.7：把“能写代码”推进到“能当搭档”

Z.ai 发布 GLM-4.7，主打更强的工程落地能力：不仅写得对，还更擅长在真实工作流里（Agent、终端、工具调用）稳定推进任务。

这次重点提升了什么？

• 核心编码与代理式开发：相较 GLM-4.6，在多语言 Agent 编程与终端任务上有明显提升；例如 SWE-bench Verified 73.8%（+5.8）、SWE-bench Multilingual 66.7%（+12.9）、Terminal Bench 2.0 41.0%（+16.5）。并强调在 Claude Code、Cline、Roo Code 等主流框架中更“好用”。
• Vibe Coding / UI 生成质量：更容易产出更现代、更干净的网页；做幻灯片时布局与尺寸更准确，整体观感更接近可直接交付的作品。
• 工具使用能力：工具调用与浏览任务的表现增强（文中提到 τ²-Bench、BrowseComp 等基准），更适合“边查边做”的复杂流程。
• 复杂推理与数学：推理能力提升，HLE（Humanity’s Last Exam）42.8%（+12.4，带工具），面向高难问题的稳健性更强。

一个很实用的新变化：更可控的“思考”机制

• Interleaved Thinking：在回复/调用工具前先思考，提高指令遵循与产出质量。
• Preserved Thinking：在多轮编码代理场景中保留推理块，减少长任务里的信息丢失与前后不一致。
• Turn-level Thinking：按回合开关推理：简单问题更省时，复杂任务更稳。

如何开始使用

• 在线体验：Z.ai Chat 里选择 GLM-4.7
• API：Z.ai 文档提供接入指南（也支持通过 OpenRouter 使用）
• 本地部署：权重已在 HuggingFace / ModelScope 提供，并支持 vLLM、SGLang 等推理框架
• 编码代理：可在 Claude Code、Cline、Roo Code、Kilo Code 等工具中使用（订阅用户可按文中指引升级模型名为 glm-4.7）

原文链接：https://z.ai/blog/glm-4.7

#GLM47 #AI编程 #Agent #工具调用 #推理能力

PostHog AI: 开发 AI 智能体一年后总结的 8 个教训PostHog 团队在开发其内置 AI 智能体 PostHog AI 的一年中，积累了丰富的实践经验

Thu, 04 Dec 2025 00:33:30 GMT

PostHog AI: 开发 AI 智能体一年后总结的 8 个教训

PostHog 团队在开发其内置 AI 智能体 PostHog AI 的一年中，积累了丰富的实践经验。从一个简单的聊天原型到一个能处理复杂分析任务的智能助手，他们总结了以下 8 个核心教训：

1. 模型升级是推土机
AI 模型的持续进步是开发中最强大的变量。曾经复杂的问题，如多步推理和工具调用，随着模型能力的提升而变得简单。密切关注模型发展至关重要.

2. 循环智能体优于固定工作流
相较于图表式的固定工作流，单一的循环智能体（Agent）更为灵活和强大。它能在执行任务中自我纠正，避免了工作流中常见的上下文丢失问题.

3. 单一循环胜过子智能体架构
复杂的子智能体架构听起来很智能，但在实践中容易因层层抽象而丢失关键信息，导致性能下降。一个简单、扁平的 LLM 循环反而能涌现出惊人的能力.

4. “待办事项”是超能力
让 LLM 在每一步操作后都使用一个简单的 `todo_write` 工具来规划下一步，这种看似简单的机制能有效帮助模型在复杂任务中保持专注和连贯性.

5. 上下文是关键
用户输入往往是模糊的，AI 需要广泛的背景知识才能准确理解. PostHog AI 通过 `/init` 命令自动学习项目信息，为智能体提供核心上下文，从而显著提升任务成功率.

6. 展示每一步，建立信任
透明度是建立用户信任的基石. 与其隐藏过程，不如将智能体的思考、工具调用甚至失败的尝试全部展示给用户. 这比一个完美的“黑箱”更能赢得信赖.

7. 警惕 AI 框架的陷阱
在 AI 技术飞速发展的今天，LangChain 等高级框架可能会过早地锁定技术选型. 在生态系统稳定之前，坚持使用更底层的库可能是更明智的选择.

8. 评估(Evals)并非全部
自动化评估很有价值，但无法替代对真实用户行为的分析. 通过观察实际使用中的 LLM 轨迹 (Traces)，团队能发现评估中无法覆盖的、更深刻的问题.

总而言之，构建高效的 AI 智能体需要拥抱变化、简化架构、重视上下文和透明度，并始终立足于真实的用户场景.

原文链接: PostHog Blog

#AI #Agent #LLM #工程实践 #PostHog

Posthog

8 learnings from 1 year of agents – PostHog AI - PostHog

Today we launch PostHog AI, the AI agent built into PostHog . A year in the making, we've gone a long way from our first chat prototype made over a…

如何让 AI Agent 高效处理长期复杂任务？当 AI 智能体（Agent）处理需要数小时甚至数天的复杂任务时，它们常常会因为上下文窗口的限制而“失忆”，导致工作中断、效率低下

Thu, 27 Nov 2025 13:41:35 GMT

如何让 AI Agent 高效处理长期复杂任务？

当 AI 智能体（Agent）处理需要数小时甚至数天的复杂任务时，它们常常会因为上下文窗口的限制而“失忆”，导致工作中断、效率低下。Anthropic 从人类软件工程师的协作模式中汲取灵感，设计了一套有效的解决方案。

核心方法分为两步：

1️⃣ 初始化智能体（Initializer Agent）

在任务开始时，该智能体首先搭建好整个工作环境。它会：
- 分解任务：将用户的高级指令分解成一个详尽的功能列表（features list）并存入 JSON 文件。
- 建立基础：创建 init.sh 启动脚本、claude-progress.txt 进度日志文件，并完成首次 Git 提交。
这确保了后续工作有清晰的目标和坚实的基础，避免了 Agent 试图一次性完成所有工作或过早宣布任务完成。

2️⃣ 编码智能体（Coding Agent）

在后续的每一个会话中，编码智能体都遵循“小步快跑”的原则：
- 聚焦单点：每次只专注于实现功能列表中的一项。
- 记录进展：完成一项功能后，通过 Git 提交代码并附上清晰的说明，同时更新进度日志文件。
- 严格测试：利用 Puppeteer 等浏览器自动化工具进行端到端测试，确保代码质量。

这种“初始化 + 增量编码”的模式，让每个 Agent 在开始新会话时，都能通过阅读日志和功能列表快速了解项目状态，确保工作连贯、高效。它有效地解决了 AI Agent 在长期任务中的一致性问题，使其能像一个纪律严明的工程团队一样协作。

阅读原文

#AI #Agent #LLM #Anthropic #软件工程

Anthropic

Effective harnesses for long-running agents

Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.