李科燃的主页

一个 Agent 在生产环境里执行了一系列操作，最终结果是错的。你怎么知道问题出在哪一步？是模型的推理出了问题，还是工具返回了错误的数据，还是 Orchestrator 给 Executor 的上下文打包有误？ 在传统服务里，这个问题有成熟的答案：日志、链路追踪、指标。三位一体的可观测性体系经过十几年的工程积累，已经相当完善。 在 Agent 系统里，这套东西从零开始。 为什么 Agent 的可观

我们团队从去年开始在几个开源项目里引入 AI Agent，处理 issue triage、PR review 辅助、依赖更新、文档检查等重复性工作。 到目前为止，有些地方跑得比预想好，有些地方踩了不小的坑。这篇是一个实践者视角的工程笔记，不是方案推销。 开源项目的特殊性在私有项目里引入 AI Agent，你控制所有参与者，可以统一制定规则。 开源项目不一样。开源项目的核心资产是社区信任——贡献者信

开源维护者的时间大多花在哪里？ 审 PR、回 issue、追依赖更新、跑 CI、做 release note——这些工作重复度高、上下文切换频繁，没有一件能完全自动化，但每一件都有一个固定的认知成本。一个中等规模的开源项目，维护者每周大概花 20-40% 的时间在这类”行政性”工作上，这个比例随着项目规模增长是线性上升的。 把 Agent 引入这个场景，逻辑上是顺的。问题是怎么做是对的。 Agen

前三篇分别讨论了 Harness 的控制边界、Agentic Memory 的检索本质、工作流编排的状态管理。这篇往上走一层：当多个 Agent 需要真正协作时，协议层是什么样的？ 已解决的问题和还没解决的问题先做一个现状判断。 工具调用协议，基本成熟。 MCP（Model Context Protocol）在过去一年里建立了事实上的标准：Server 暴露工具，Client（即 Agent）发现

大多数 Agent 失败不是因为模型不够聪明，而是因为任务结构不对。 给一个 Agent 一个模糊的长任务，它会开始推理、执行、出错、自我修正，然后在某个节点彻底偏离轨道。这个现象在复杂任务里几乎是必然的，不是 Agent 能力的问题，是任务组织方式的问题。 工作流编排解决的就是这个问题：如何把一个复杂任务拆解成 Agent 可以可靠执行的结构，并在多个 Agent 之间协调执行。 先说清楚”工作

几乎所有团队在第一次遇到 Agent 记忆问题时，第一反应都是去找一个向量数据库。 这个直觉不完全错，但它把问题想窄了。Agent 的记忆问题不是”怎么存”，而是”在对的时刻，把对的东西喂给模型”。这是一个检索问题，存储只是检索的前提条件。 先把问题说清楚Agent 在执行任务时，有两种截然不同的”遗忘”场景： 场景一：上下文窗口溢出。 任务进行到中途，历史对话和工具调用记录超出了模型的 cont

过去一年，”Agent” 这个词被用得极度滥泛。几乎所有能调用 LLM 的系统都开始自称 Agent，从一个简单的 prompt chain 到复杂的多智能体协作框架，混在一起难以区分。 真正值得关注的，是那些在生产环境里实际跑起来的系统，背后有一套东西把它们撑起来——不是模型本身，而是围绕模型构建的控制结构。这个控制结构，我习惯称之为 Harness。 Harness 不是 Framework先

聊 LLM 推理并行策略的文章很多，大多数的结论长这个样子：DP 适合模型单卡放得下的场景，TP 适合单层参数量大的情况，PP 适合层数多的模型，实际部署用 3D 并行。 这些话都对，但都没说清楚一件事：这个决策树背后的约束是什么。 技术选型不是在菜单上挑菜，每个选项背后都有它成立的前提条件。理解前提比记住结论更有用。 通信是并行策略的真正成本三种并行策略——数据并行（DP）、张量并行（TP）、

Anthropic 今天发布了 Model Context Protocol（MCP）。 消息不算意外。任何在生产环境跑过 AI Agent 的人都会遇到同一堵墙：模型能推理，但它摸不到数据。每接一个数据源，就要写一套胶水代码。这件事不优雅，也不可持续。 MCP 试图解决的，就是这个问题。 问题本质：上下文孤岛能力和上下文是两件事。 过去两年，业界花了大量资源在模型能力上——推理、长文本、多模态

放下手机，回归真实一、原作者的观点原作者（微博suelence）通过自己的经历，深刻地揭示了手机对人们生活的影响。她指出： 手机让我们逃避现实：在无聊的时候拿起手机，因为我们失去了观察世界的乐趣和能力。 手机让我们失去感知力：太久的虚拟生活，让长着五官手脚的我们，活得越来越没有感受力。 手机影响睡眠质量：睡觉前听广播会影响我们的睡眠质量，让我们失去了自然入睡的能力。 手机影响人际关系：过度使用手