WRITING

文章

多 Agent 系统的收益，取决于任务怎么拆

一次代码评审可以交给一个 Agent 从头做到尾，也可以拆给几个 Agent 并行检查。后者什么时候值得做？关键要看任务能否独立完成，以及结果怎样交接。

一个复杂 Agent 往往要连续规划、调用工具、处理失败并验证结果。只要其中一环缺少边界，任务即使跑完也可能无法交付。本文从一次跑偏的 CI 排障开始，拆解开发中最常见的五类挑战。

新项目默认用 pnpm，旧仓库仍然需要 npm ci。两条规则都没错，Agent 却在下一次创建项目时选错了工具。问题藏在 Memory 写入时丢失的作用域里。

你昨天刚交代过的事，Agent 到了新会话却像第一次听见。很多时候，不是模型忘了，而是应用没有把那条信息存下来，也没有在需要时找回来。

计划不是越长越好。本文从一个 Go 服务迁移任务出发，拆解 Plan-and-Execute、Replanning、ToT、GoT、Reflexion 与经典规划器各自解决的问题。

从一次失败的 CI 排查开始，理解 Thought、Action、Observation 与 Runtime 如何让 Agent 根据环境反馈调整下一步。

从读取代码、运行测试到根据报错调整方案，Agent 的能力藏在每一次“做完再看”的循环里。本文把模型、工具、状态、记忆、运行时和停止条件逐一拆开。

程序员不应该只被简历和技术关键词定义。Made by Arjun 用作品和思考，记录把模型能力变成可靠系统的过程。

从一句服务调用出发，跟着一个 token 走完 Self-Attention：看它如何生成 Query、Key、Value，计算 Attention Weights，并在 Multi-Head Attention 中汇总上下文。