AI 基础设施
Agent 系统的安全工程：当 LLM 拥有真实的工具权限
传统 LLM 应用的安全问题，主要是输出质量问题：模型说了不该说的话，或者被诱导输出了有害内容。这类问题的影响范围，大致等于"一个人能说的话"的影响范围。 Agent 系统的安全问题性质不同。当 LLM 拿到了工具——可以写文件、调 API、执行代码、提交代码库、发送消息——"输出"就不再是文本，而
AI 基础设施
Agent 系统的可观测性：你不能控制你看不见的东西
一个 Agent 在生产环境里执行了一系列操作，最终结果是错的。你怎么知道问题出在哪一步？是模型的推理出了问题，还是工具返回了错误的数据，还是 Orchestrator 给 Executor 的上下文打包有误？ 在传统服务里，这个问题有成熟的答案：日志、链路追踪、指标。三位一体的可观测性体系经过十几
开源
在开源项目里跑 AI Agent：维护者视角的工程笔记
我们团队从去年开始在几个开源项目里引入 AI Agent，处理 issue triage、PR review 辅助、依赖更新、文档检查等重复性工作。 到目前为止，有些地方跑得比预想好，有些地方踩了不小的坑。这篇是一个实践者视角的工程笔记，不是方案推销。 开源项目的特殊性 在私有项目里引入 AI Ag
开源
AI Maintainer：把 Agent 引入开源社区治理的工程边界
开源维护者的时间大多花在哪里？ 审 PR、回 issue、追依赖更新、跑 CI、做 release note——这些工作重复度高、上下文切换频繁，没有一件能完全自动化，但每一件都有一个固定的认知成本。一个中等规模的开源项目，维护者每周大概花 20-40% 的时间在这类"行政性"工作上，这个比例随着项
AI 基础设施
多 Agent 协调的协议层：工具调用之外，还缺什么
前三篇分别讨论了 Harness 的控制边界、Agentic Memory 的检索本质、工作流编排的状态管理。这篇往上走一层：当多个 Agent 需要真正协作时，协议层是什么样的？ 已解决的问题和还没解决的问题 先做一个现状判断。 工具调用协议，基本成熟。 MCP（Model Context Pro
AI 基础设施
AI Agent 工作流编排：从任务分解到多智能体协调
大多数 Agent 失败不是因为模型不够聪明，而是因为任务结构不对。 给一个 Agent 一个模糊的长任务，它会开始推理、执行、出错、自我修正，然后在某个节点彻底偏离轨道。这个现象在复杂任务里几乎是必然的，不是 Agent 能力的问题，是任务组织方式的问题。 工作流编排解决的就是这个问题：如何把一个
AI 基础设施
Agentic Memory 的工程本质：不是存储问题，是检索问题
几乎所有团队在第一次遇到 Agent 记忆问题时，第一反应都是去找一个向量数据库。 这个直觉不完全错，但它把问题想窄了。Agent 的记忆问题不是"怎么存"，而是"在对的时刻，把对的东西喂给模型"。这是一个检索问题，存储只是检索的前提条件。 先把问题说清楚 Agent 在执行任务时，有两种截然不同的
云原生
AI Agent Harness 的工程本质：从控制边界到协作基础设施
过去一年，"Agent" 这个词被用得极度滥泛。几乎所有能调用 LLM 的系统都开始自称 Agent，从一个简单的 prompt chain 到复杂的多智能体协作框架，混在一起难以区分。 真正值得关注的，是那些在生产环境里实际跑起来的系统，背后有一套东西把它们撑起来——不是模型本身，而是围绕模型构建
AI 基础设施
大模型推理的并行约束：硬件拓扑决定你能做什么
聊 LLM 推理并行策略的文章很多，大多数的结论长这个样子：DP 适合模型单卡放得下的场景，TP 适合单层参数量大的情况，PP 适合层数多的模型，实际部署用 3D 并行。 这些话都对，但都没说清楚一件事：这个决策树背后的约束是什么。 技术选型不是在菜单上挑菜，每个选项背后都有它成立的前提条件。理解前
AI 基础设施
MCP：给 AI Agent 一个标准化的工具插座
Anthropic 今天发布了 Model Context Protocol（MCP）。 消息不算意外。任何在生产环境跑过 AI Agent 的人都会遇到同一堵墙：模型能推理，但它摸不到数据。每接一个数据源，就要写一套胶水代码。这件事不优雅，也不可持续。 MCP 试图解决的，就是这个问题。 ---