Agili

  1. 给 Agent 的临时邮箱,应该长这样

    给 Agent 的临时邮箱,应该长这样

    我测试了 TempMail.Best 的 Agent Skill。安装、创建邮箱、收信、读取正文和删除邮箱,整条流程都能由 Agent 完成,不需要打开网页,也不用人工接力。

    邮箱可设置为 10 分钟或 1 小时有效期。邮件列表和正文通过 HTTP API 获取,Token 放在 Authorization: Bearer 中,不会出现在 URL。text 和 HTML 正文都能读取,适合验证码、确认链接、投递检查和端到端测试。

    我跑了一次完整流程:创建 10 分钟邮箱,用 SendTestMail 发信,Agent 成功读到主题、发件人和正文,最后删除邮箱。创建前还需要完成 Cap proof-of-work。它不依赖浏览器环境,但保留了防滥用成本,这个设计很合理。

    边界也很清楚:

    • 每个邮箱只保留最新 20 封邮件。
    • 新邮件不会延长邮箱寿命。
    • HTML 邮件属于非可信输入,不能直接执行或无隔离渲染。
    • 创建挑战有频率限制,不适合高并发批量注册。

    TempMail.Best 更像 Agent 工作流里的临时邮件 I/O,而不是面向普通用户的隐私邮箱。做注册测试、邮箱验证和邮件链路验收时,很顺手。

    安装:https://tempmail.best/INSTALL.md
    Skill:https://tempmail.best/skills/tempmail-best/SKILL.md
    OpenAPI:https://tempmail.best/api/agent/v1/openapi

  2. GPT-5.6 Sol 放进真实工作流后表现怎样

    GPT-5.6 Sol 放进真实工作流后表现怎样

    Claire Vo 在 How I AI 中比较了 GPT-5.6 Sol、Terra、Luna,以及 Claude Fable 5 和 Sonnet 5。测试不是单纯跑 Benchmark,而是覆盖 PRD、原型、前端设计、调试、Agent 语气、浏览器操作和视频剪辑。

    她的体验是:Fable 更擅长复杂推理,但沟通成本偏高;Sol 更像实用型执行者,做 0→1 原型、Dashboard 和开发者工具页面时,输出更完整,也更愿意做取舍。PRD 写作她反而偏 Terra,Agent 语气则认为 Sonnet 5 更自然。

    这套评价标准比排行榜更接近真实开发:模型能否理解目标,把页面、代码和流程推进到可试用状态,而不是生成一份看起来完整的分析。

    也别忽略限制。GPT-5.6 当时仍是有限预览,安全策略可能误拦部分正常工作;企业也开始更严格地控制 Token 成本。模型更便宜,不等于可以不算账。

    如果你做 AI 编程、产品原型或 Agent 工作流,这期值得看。重点不是谁“赢了”,而是不同模型分别适合承担什么工作。

    视频:https://www.youtube.com/watch?v=gAWbvEwUoiI
    官方说明:https://openai.com/index/previewing-gpt-5-6-sol/

  3. Yansu 会观察工作方式,再主动生成小工具

    Yansu 会观察工作方式,再主动生成小工具

    Yansu 的定位不是聊天助手。它通过桌面截图、消息应用和日常工作流识别重复模式,再生成内部工具、Dashboard、Tracker 或自动化流程。

    它支持 macOS、Windows 和 Linux,可连接 Slack、Teams、飞书、Discord、Telegram、WhatsApp 和微信。记忆、对话及生成的应用以本地存储为主。后台 Computer Use 仍在开发中,目标是在虚拟层完成任务,不占用鼠标和焦点。

    这个方向比“等用户写 Prompt”更进一步:很多人知道工作重复,却说不清该造什么工具。Yansu 如果能从行为中抽象需求,确实可能省下一批内部软件。

    风险也同样直接。持续观察桌面和消息意味着很高的权限;生成工具的质量取决于它是否真正理解业务,而不是只做一个漂亮页面。目前公开讨论较少,仍是早期产品。

    建议先接低风险流程,例如任务追踪、会议行动项或 AI 费用统计。别一开始就把核心客户数据和关键操作交给它。

    官网:https://yansu.app/ Yansu — The proactive AI that turns how you work into knowledge, handoffs, and automations

  4. Paseo 把多个 Coding Agent 接到同一个入口

    Paseo 把多个 Coding Agent 接到同一个入口

    Paseo 是一个开源的 Claude Code、Codex、Copilot 和 OpenCode 统一入口。它通过自建 Daemon 连接本地电脑或 VPS,再提供桌面端、移动端、Web 和 CLI。

    你可以同时运行多个 Agent,用 Worktree 隔离任务,也可以让一个模型制定计划、另一个模型执行,再回收结果。手机更适合查看进度、Diff 和补充指令,真正的构建与测试仍在后端机器上完成。

    这类工具解决的是上下文和设备切换,不会降低模型费用,也不会让不稳定的网络或开发环境自动变好。它最大的吸引力,是代码和执行环境仍由自己控制。

    如果你经常在多台设备间切换,或已经在做多 Agent 编排,Paseo 值得试。只在单机终端里跑一个 Agent,就没必要为了统一而统一。

    项目:https://paseo.sh/ Paseo – Run Claude Code, Codex, Copilot, OpenCode from anywhere

  5. OpenAI 给 Claude Code 做了 Codex 插件

    OpenAI 给 Claude Code 做了 Codex 插件

    openai/codex-plugin-cc 把 Codex 接入 Claude Code,可以通过斜杠命令调用:

    • /codex:review:只读代码审查
    • /codex:adversarial-review:挑战设计假设并检查风险
    • /codex:rescue:交给 Codex 排查 Bug 或提出修复方案,可在后台运行
    • /codex:status、/codex:result、/codex:cancel:管理后台任务

    它的价值不是让两个模型互相聊天,而是把审查、质疑和故障排查固定成可复用流程。Claude Code 负责主线实现,Codex 作为第二视角检查结果,适合迭代快、又不想放弃质量门槛的项目。

  6. Vite 8 用 Rolldown 统一构建引擎

    Vite 8 用 Rolldown 统一构建引擎

    Vite 8 最大的变化,是把开发和生产构建统一到 Rust 编写的 Rolldown。过去 Vite 在不同阶段分别依赖 esbuild 和 Rollup,速度快,但两套流程难免产生行为差异。现在底层统一,官方希望同时获得性能、兼容性和更大的优化空间。

    官方数据里,Rolldown 相比 Rollup 快 10~30 倍。部分真实项目的构建时间也明显下降:Linear 从 46 秒降到 6 秒,Ramp 下降 57%,Beehiiv 下降 64%。

    这次还加入了 Devtools、tsconfig paths、emitDecoratorMetadata、Wasm SSR,以及能把浏览器 Console 转发到终端的 server.forwardConsole。后者对前端 Agent 调试尤其有用。

    新项目可以直接用。老项目如果有大量自定义插件、Rollup 配置或特殊 Loader,先在分支和 CI 验证产物。Node 版本要求仍是 20.19+ 或 22.12+,tsconfigPaths 也不是默认开启。

    Vite 8 不是功能堆叠,而是在还一笔长期架构债。这种升级比再加十个配置项更值钱。

    原文:https://vite.dev/blog/announcing-vite8
    插件目录:https://registry.vite.dev Vite 8.0 is out!

  7. 公网里的 OpenClaw 已经会被扫描和归档

    公网里的 OpenClaw 已经会被扫描和归档

    OpenClaw Exposure Watchboard 收集互联网上可访问的 OpenClaw 实例,并标记认证状态、活跃状态、疑似凭据泄露、机房和相关漏洞信息。

    这类看板最值得关注的不是实例总数,而是权限差异。普通博客暴露在公网,风险通常停留在内容和服务器;OpenClaw 可能读消息、调用工具、执行命令。一旦入口裸露,后果完全不是一个量级。

    运行 OpenClaw 时,至少做到这些:

    • 开启认证,不直接暴露 Gateway 或 Agent 端口。
    • 放在 Zero Trust、内网或带鉴权的反向代理后。
    • 及时升级,并收紧消息、文件和命令执行权限。
    • 定期检查公网暴露面和日志。

    Agent 开始进入“默认会被扫描”的阶段。先补安全基线,再接真实生活和生产环境。

    看板:https://openclaw.allegro.earth/ OpenClaw Exposure Watchboard

  8. mcp2cli:工具很多时,别把所有 Schema 都塞进上下文

    mcp2cli:工具很多时,别把所有 Schema 都塞进上下文

    mcp2cli 可以在运行时把 MCP、OpenAPI 或 GraphQL 服务转换成 CLI。Agent 先查看命令目录,真正需要某个能力时,再通过 --list 或 --help 获取参数并执行。

    它解决的是一个很现实的问题:工具越多,常驻在上下文里的 Schema 越大。Agent 还没开始工作,Token 已经先花在说明书上。mcp2cli 把这部分改成按需发现,项目给出的测试数据是节省 96%~99% 的上下文。

    代价也很明确:发现命令会增加调用步骤和延迟;如果本来只有两三个简单工具,收益未必值得。作者的 Benchmark 也不能替代真实业务测试。

    我的判断是,这个方向靠谱。MCP 解决如何连接工具,mcp2cli 处理连接之后的上下文成本。工具数量多、接口 Schema 重时,值得试。

    项目:https://github.com/knowsuchagency/mcp2cli
    背景:https://kanyilmaz.me/2026/02/23/cli-vs-mcp.html GitHub - knowsuchagency/mcp2cli: Turn any MCP, OpenAPI, or GraphQL server into a CLI — at runtime, with zero codegen

  9. Cloudflare 在边缘把网页转换成 Markdown

    Cloudflare 在边缘把网页转换成 Markdown

    Cloudflare 发布了 Markdown for Agents Beta。开启后,客户端发送 Accept: text/markdown,Cloudflare 会在边缘节点把网页 HTML 转成 Markdown,再返回给 Agent。

    官方示例中,一篇博客从约 1.6 万 Token 降到约 3000 Token。源站不需要安装转换插件,Pro、Business、Enterprise 和 SaaS 计划在 Beta 阶段可用。

    响应还会包含 Content-Signal,用来表达内容是否允许用于搜索、训练等用途。这比只做格式转换更完整:既降低 Agent 的解析成本,也让网站能声明内容使用边界。

    它不能解决所有网页抓取问题。动态交互、登录态和结构复杂的应用仍需要浏览器。但对于文章、文档和知识库,这是很省事的一层基础设施。

    原文:https://blog.cloudflare.com/markdown-for-agents/ Introducing Markdown for Agents

  10. GitHub Agentic Workflows:用自然语言写仓库自动化

    GitHub Agentic Workflows:用自然语言写仓库自动化

    GitHub Agentic Workflows(gh-aw)允许维护者用自然语言描述任务,再由 Agent 在 GitHub Actions 中执行。典型场景包括 Issue 分类、PR Review、文档维护和带条件判断的自动化流程。

    它真正的优势不是“自然语言”,而是原生接入仓库权限、Actions 环境和现有生态。相比额外部署一套 Agent 平台,维护成本低得多。

    安全仍是关键。Agent 能读仓库、运行命令并修改内容,工作流必须限制权限、隔离执行环境,并让高风险写操作经过审查。否则只是把 CI 的确定性问题换成更难排查的概率性问题。

    开源项目维护者可以先从只读和低风险任务开始试,不建议一上来就把发布或合并权限交出去。

    项目:https://github.com/github/gh-aw GitHub - github/gh-aw: GitHub Agentic Workflows

  11. WebMCP 让网页直接告诉 Agent 能做什么

    WebMCP 让网页直接告诉 Agent 能做什么

    浏览器 Agent 目前常靠截图识别或 DOM 分析操作网页。页面样式或结构一变,自动化就可能失效。WebMCP 提出的办法更直接:网站主动声明可用工具、参数和用途,让 Agent 调用明确的接口。

    它提供两种方式:

    • JavaScript API:通过 navigator.modelContext.registerTool 注册工具,适合复杂应用。
    • HTML 声明:在 form 和 input 上增加工具名称、描述和参数信息,浏览器自动转换为 Agent 可识别的 Tool。

    第二种尤其有 Web 味。语义化 HTML 过去主要服务搜索引擎和无障碍工具,以后也可能成为 Agent 的操作说明书。

    WebMCP 仍是实验性提案,距离稳定标准还有距离。但思路很清楚:能让网页明确表达能力,就别让 Agent 靠猜。

    参考:https://docs.google.com/document/d/1rtU1fRPS0bMqd9abMG_hc6K9OAI6soUy3Kh00toAgyk/mobilebasic

  12. Entire 想把 AI 编程过程放进 Git

    Entire 想把 AI 编程过程放进 Git

    GitHub 前 CEO Thomas Dohmke 创办了 Entire.io,并完成 6000 万美元种子轮融资。它的第一个开源产品 Entire CLI,会在使用 Claude Code 等 Agent 编程时保存会话,并将这些记录作为元数据写入 Git 仓库的 entire/checkpoints/v1 分支。

    普通 Git 历史能告诉你代码改了什么,却很少保留当时的目标、提示词和试错过程。Agent 参与开发后,这部分上下文越来越重要:下一位开发者或下一次 Agent 会话,需要知道为什么这样改,而不只是看到最终 Diff。

    Entire 的 Checkpoints 正在尝试把这些过程变成可版本化资产。方向是对的,但也要注意仓库体积、敏感信息和会话噪音。什么都保存并不等于什么都有用。

    项目:https://github.com/entireio/cli Entire · The Git forge for agents

  13. 把 Cloudflare Browser Rendering 变成通用 CDP 服务

    把 Cloudflare Browser Rendering 变成通用 CDP 服务

    面条开源了 cf-browser-cdp。它部署在 Cloudflare Workers 上,把 Browser Rendering 封装成标准的 CDP WebSocket 服务。

    Cloudflare 的浏览器原本主要通过 Worker Binding 调用。加上这层代理后,本地脚本、Vercel、AWS,以及其他支持 WebSocket 的环境,都可以直接用 Playwright 或 Puppeteer 连接。

    这也适合 Agent:chrome-devtools-mcp、agent-browser 等工具可以复用标准 CDP,不必为云端浏览器单独适配 Cloudflare,更不用维护一套常驻 Docker 浏览器。

    我喜欢这个项目的原因很简单:它没有再造协议,只是把 Cloudflare 已有能力接到通用接口上。代码少,运维轻,适用面反而更广。

    项目:https://github.com/miantiao-me/cf-browser-cdp GitHub - miantiao-me/cf-browser-cdp: Connect Cloudflare Browser Rendering via CDP (Chrome DevTools Protocol).

  14. Stripe 的 Minions 每周提交超过 1000 个 PR

    Stripe 的 Minions 每周提交超过 1000 个 PR

    Stripe 公开了内部 Coding Agent「Minions」的工作方式。工程师在 Slack 里提交任务后,Agent 会进入隔离的 Devbox,修改代码、运行测试、修复 Lint,最后创建 PR。人只负责检查结果。

    Minions 基于 Block 的 goose,并通过 MCP 接入 Stripe 的 Ruby、Sorbet 单体仓库和内部工具。难点不在生成代码,而在理解依赖、遵守工程规范,并顺利通过现有 CI。

    Stripe 已经让 Minions 每周独立完成超过 1000 个 PR。这说明无人值守 Coding Agent 能否落地,主要取决于工具链和环境,而不是聊天界面。

    对独立开发者也一样:先把测试、文档、部署和内部工具做成稳定接口,再谈 Agent 自动干活。模型会继续变强,但混乱的工程环境不会自动变好。

    来源:https://stripe.dev/ Stripe Dot Dev

  15. 把资讯筛选交给 Agent

    把资讯筛选交给 Agent

    每天刷上千条 AI 资讯,真正费时间的不是阅读,而是判断什么值得读。AIGC Weekly 背后的做法,是把这套判断过程写成一条自动流水线:

    1. 从 RSS、X 和 GitHub Trending 收集候选内容。
    2. 用 Stars、来源质量、主题相关性等规则先过滤噪音。
    3. 让 Claude 或 Gemini 阅读原文,生成摘要并提取值得讨论的部分。
    4. 自动发布到 Telegram 和博客。

    这套流程最有价值的地方,是把个人品味变成可执行的筛选规则。周刊作者不再重复搬运信息,而是持续调整规则:哪些来源可信,什么主题值得跟进,哪些内容只是热闹。

    整条链路运行在 Cloudflare Workers 上,成本低,也不需要长期维护服务器。对于长期做内容的人,这比单纯让 AI “帮我总结一下”实用得多。

    项目:GitHub / miantiao-me / AIGC Weekly Agent