Glean 拾遗
最近收录

5 条 · 按时间

06-28

循环工程:构建不会在睡着时烧掉你预算的自动化循环技术路线图

本文是一份构建可靠自主循环(autonomous loop)的技术路线图,作者强调循环不是prompt——prompt需要你手动触发,而循环自己驱动自己:设定目标后,系统自动查找工作、执行、检查、修复、重复直至完成。核心论点:决定上限的不是写prompt的技能,而是构建一个能收敛到真理而非变成昂贵随机漫步的循环。文章按严格顺序提供从Step 0到Step 7的实操指南,包含完整代码(Bash脚本)、每次迭代重建上下文的stateless设计原理(对付context rot)、不可被欺骗的check设计(独立oracle + reward hacking防御门 + 独立法官)、磁盘状态协议(human-readable STATUS.md + machine-parsable JSON)、隔离(worktree/container with --network none)、刹车(迭代上限、预算上限、重复检测器、liveness marker、结构化日志)、以及成本非线性增长分析。特别适合需要构建AI Agent自动化流水线的一线工程师阅读。

06-26

跨 AI 编码助手的智能体增强操作系统——规则、技能与安全审计

ECC 是一套为多个 AI 编码助手(Claude Code、Cursor、Codex、OpenCode、GitHub Copilot 等)设计的智能体增强系统,被定位为“Agent 增强型操作系统”。它并非一个独立的 AI 工具,而是一个包含 260+ 技能、67+ 子智能体、提供持久化记忆、连续学习、成本优化和安全审计(AgentShield)等功能的配置与插件集合。通过统一的规则、钩子和 MCP 配置,它试图解决跨平台开发工作流中智能体行为不一致、上下文丢失和安全性不足的问题。适合深度使用 AI 编码助手的专业开发者,以及希望建立标准化 Agent 工程实践的技术团队。

github.com · 94 min · Agent Engineering · Claude Code · Context Engineering
06-15

将 agent harness 拆解为可独立替换的 workers:iii 引擎的架构实验

作者 Mike Piccolo 提出了一个观点:当前主流的 agent 框架(如 LangGraph, CrewAI)将循环、工具、记忆、审批等职责捆绑为一个整体,导致团队后期不得不重写整个 harness。他介绍了 iii 引擎的 worker 架构,将 agent 运行所需的 13 项职责(凭证解析、策略检查、会话持久化、预算追踪等)拆分为 11 个独立的 worker。每个 worker 通过同一个 WebSocket 原语(iii.trigger) 在总线上注册函数和触发器,能够像积木一样被单独添加、移除或替换。文中用生产环境的实例拆解了从 API 请求到 turn 状态机、流式响应、工具调用审批、预算记账和 OpenTelemetry 追踪的全链路,并给出了替换模型目录、新增模型供应商、私有 skill 存储、自定义审批界面等 5 个具体替换案例。核心论断是:agent harness 不应是一个需要被 fork 的单一框架,而应是一组可组装、独立版本化的 worker 合集,使架构从“选边站”的厚薄之争,变为一个可由配置文件滑动调节的连续体。本文适合在自建 agent 系统中遇到框架边界限制,或对松耦合 agent 基础设施设计感兴趣的后端工程师。

06-08

Maple:基于 OpenTelemetry + ClickHouse 的开源可观测性平台

Maple 是一个开源可观测性平台,提供 traces、logs、metrics 的采集、存储与可视化能力。它采用 OpenTelemetry 标准与 ClickHouse 存储,采用 Effect 驱动的后端 API 和 TanStack SPA 前端。项目以 monorepo 形式组织,包含 OTLP 数据摄取网关、告警引擎、仪表板持久化等组件,支持 Clerk 或自托管认证,适合希望自建可观测性栈且偏好 TypeScript 工程体系的团队。

github.com · 9 min · ClickHouse · Cloudflare · Monorepo
06-05

OpenTelemetry 推出 Blueprints 计划:以预设架构与参考实现降低企业可观测性落地门槛

OpenTelemetry 正式发布 Blueprints 计划,旨在应对大规模可观测性部署中日益增长的复杂性。该计划提供面向常见场景的预设架构模式、运营最佳实践和分步实施指南,并配套由 Adobe、Mastodon、Skyscanner 等企业贡献的参考实现。文章剖析了可观测性的“必要复杂性”与“偶然复杂性”,指出组织在有机采用 OpenTelemetry 时常因缺乏集中标准而导致遥测管道碎片化、语义约定不一致及上下文传播断裂。Blueprints 不替代现有文档,而是将架构、运营和实现步骤整合为可复用的策略,重点关注 Kubernetes 可观测性、非 Kubernetes 基础设施检测和集中式遥测平台架构。此举标志着可观测性生态从纯模块化工具向更具指导性的运营框架转变,目标是在保持厂商中立与灵活性的同时,降低大规模运维的认知负荷。适合面临可观测性规模化挑战的平台工程、DevOps 和 SRE 团队阅读。

www.infoq.com · 5 min · Cloud Native · Kubernetes · Observability