吃透 AI Agent 开发
https://v833.github.io/agent-engineering/
2026-07-31T00:00:00+08:00
从一个用户请求出发，完整拆解 Agent 的认知、Loop、工具、上下文、记忆、协作、Harness 与质量保障。文章重点放在可以迁移到不同项目的工程思想。
结课：从 10 行代码到 Agent 六大支柱
https://v833.github.io/2026/07/31/agent-engineering-course-conclusion/
2026-07-31T00:00:00+08:00
把 33 篇内容重新串成一条判断路径：先看任务，再看上下文、工具、状态、协作和质量，而不是先问该用哪个框架。
从本地 Agent 到可交付产品：可靠性、部署与降级
https://v833.github.io/2026/07/29/agent-reliability-deployment-and-degradation/
2026-07-29T00:00:00+08:00
部署后要面对网络、模型限流、上下文过长、外部服务不可用和进程崩溃。可靠性来自明确的降级和恢复协议。
如何验证一个 Agent：可观测性、测试与 Eval
https://v833.github.io/2026/07/27/agent-observability-testing-and-evaluation/
2026-07-27T00:00:00+08:00
没有报错不代表完成任务。日志、轨迹、单元测试、集成测试和 Eval 要共同回答发生了什么、是否正确以及是否退化。
Agent Harness：把模型能力变成可重复的工作系统
https://v833.github.io/2026/07/24/agent-harness-architecture/
2026-07-24T00:00:00+08:00
真正稳定的 Agent 依赖的不只是模型，还包括配置、工具、状态、策略、事件、恢复和运行入口组成的 Harness。
多 Agent 编排模式：什么时候并行，什么时候串行
https://v833.github.io/2026/07/19/multi-agent-orchestration-patterns/
2026-07-19T00:00:00+08:00
并行能缩短等待，但会增加重复、合并和限流成本。编排应该由任务依赖和证据需求决定。
多 Agent 协作：上下文隔离、后台执行与通信
https://v833.github.io/2026/07/14/multi-agent-isolation-background-and-communication/
2026-07-14T00:00:00+08:00
多 Agent 不是简单复制线程。任务边界、上下文隔离、结果预览、通知和生命周期才是协作的难点。
流式交互界面：事件驱动设计如何承接 Agent
https://v833.github.io/2026/07/09/agent-streaming-ui-event-driven-design/
2026-07-09T00:00:00+08:00
模型文本、工具进度、后台通知和输入状态会同时变化，界面应该消费语义事件，而不是直接监听内部函数。
本地文件、图片附件与可回滚写入：让 Agent 改得起也退得回
https://v833.github.io/2026/07/04/agent-local-files-attachments-and-rewind/
2026-07-04T00:00:00+08:00
路径边界、图片临时注入、写前快照和冲突检测共同决定 Agent 改文件是否可控。
规划与任务系统：从自然语言意图到可执行任务图
https://v833.github.io/2026/06/29/agent-planning-and-task-state-machine/
2026-06-29T00:00:00+08:00
“先给计划，不要执行”、进度清单和持久化任务图是三件不同的事，应该由不同状态和模块负责。
记忆会坏：五种失效模式和工程解法
https://v833.github.io/2026/06/24/agent-memory-failure-modes/
2026-06-24T00:00:00+08:00
记忆可能过时、冲突、过度泛化、被污染或无法追溯。可靠记忆需要年龄、来源、验证和删除机制。
Agent 的记忆系统：文件派、数据库派和生命周期
https://v833.github.io/2026/06/19/agent-memory-system/
2026-06-19T00:00:00+08:00
聊天记录、会话状态、项目记忆和用户偏好生命周期不同。先分层，再决定文件还是数据库。
LLM 编译知识库：让零散经验变成可连接的系统
https://v833.github.io/2026/06/14/knowledge-compilation-for-agents/
2026-06-14T00:00:00+08:00
知识库不是文件堆。把结论、来源、关系、版本和验证状态结构化，Agent 才能持续积累而不是重复聊天。
检索优化：语义相似不等于任务相关
https://v833.github.io/2026/06/09/retrieval-optimization-for-agent/
2026-06-09T00:00:00+08:00
用户问的是“我现在该改哪里”，检索却可能返回一堆“概念相似”的旧文章。任务、权限、时间和证据都要进入排序。
RAG 全流程：从一堆文档到 Agent 能用的知识库
https://v833.github.io/2026/06/04/rag-pipeline-for-agent-knowledge/
2026-06-04T00:00:00+08:00
RAG 不只是向量检索。切分、元数据、召回、重排、引用和过期处理共同决定知识能不能被可靠使用。
Just-In-Time Context：信息不是越早塞越好
https://v833.github.io/2026/05/30/just-in-time-context/
2026-05-30T00:00:00+08:00
启动时把所有文件、工具和记忆都塞给模型，会让上下文拥挤且陈旧。按需读取更接近真实工作。
Cache 与成本控制：稳定前缀为什么值钱
https://v833.github.io/2026/05/25/prompt-cache-cost-control/
2026-05-25T00:00:00+08:00
Prompt Cache、KV Cache、Context Collapse 不是一回事。理解缓存边界，才能解释延迟和成本为什么突然上升。
上下文快爆了怎么办：压缩、预算与 Offload
https://v833.github.io/2026/05/20/context-compression-budget-and-offload/
2026-05-20T00:00:00+08:00
对话、工具输出和子任务结果都会增长。压缩保留语义，预算控制注入，Offload 保存完整正文，三者不能混为一谈。
System Prompt 工程化：稳定规则与动态上下文怎么分层
https://v833.github.io/2026/05/15/system-prompt-engineering-and-context-rot/
2026-05-15T00:00:00+08:00
把 Prompt 变成带稳定性和类别元数据的管道，避免每轮变化的 Git 状态、日期和任务列表污染稳定前缀。
Context Engineering 全景：上下文不是一段 Prompt
https://v833.github.io/2026/05/10/context-engineering-five-dimensions/
2026-05-10T00:00:00+08:00
上下文同时涉及选择、顺序、预算、时机和新鲜度。只会写 system prompt，还远远不够。
你敢让 AI 直接跑 rm -rf 吗：生产级权限的四层防线
https://v833.github.io/2026/05/05/agent-permission-defense-in-depth/
2026-05-05T00:00:00+08:00
权限不是工具名称上的一个 readonly 标记，而是路径、参数、环境、审批和审计共同组成的纵深防线。
MCP 的工程真相：协议很好，但连接不是免费的
https://v833.github.io/2026/04/30/mcp-engineering-reality/
2026-04-30T00:00:00+08:00
MCP 让远程能力有了统一插槽，但连接、超时、版本、权限和数据边界仍然要由宿主应用负责。
工具太多模型选不准：Deferred Loading 与动态工具集
https://v833.github.io/2026/04/25/dynamic-tool-loading-and-deferred-tools/
2026-04-25T00:00:00+08:00
工具描述也占上下文。工具数量变多后，按需加载、搜索和动态注册比把全部工具常驻更可靠。
一次工具调用背后发生了什么：从意图到副作用
https://v833.github.io/2026/04/20/tool-execution-pipeline/
2026-04-20T00:00:00+08:00
把一次读文件或跑命令拆成可检查的流水线，才能知道问题出在参数、路径、进程、输出还是模型理解。
工具系统：统一执行入口为什么比工具函数更重要
https://v833.github.io/2026/04/15/agent-tool-system-unified-execution-boundary/
2026-04-15T00:00:00+08:00
工具一多，超时、权限、Hook、审计和结果裁剪不能靠每个函数各写一套。注册表是副作用的统一边界。
Function Calling 与 Structured Output：模型如何学会调用函数
https://v833.github.io/2026/04/10/function-calling-and-structured-output/
2026-04-10T00:00:00+08:00
工具调用不是模型直接执行代码，而是模型按照 schema 表达一个结构化意图，再由应用决定是否执行。
流式响应、Reasoning 与重试：不要把模型输出当一段字符串
https://v833.github.io/2026/04/05/agent-loop-streaming-reasoning-retry/
2026-04-05T00:00:00+08:00
模型返回的可能是文字、思考、工具调用、用量和警告。正确拆分这些 part，才能同时做好 UI、审计和下一轮请求。
把 Agent Loop 做成状态机：每一步到底处于什么状态
https://v833.github.io/2026/03/31/agent-loop-state-machine/
2026-03-31T00:00:00+08:00
当 Loop 加入中断、重试、并发和后台任务后，单个布尔值 done 已经不够。显式状态能让行为可测试。
Agent Loop：模型、工具与消息如何形成闭环
https://v833.github.io/2026/03/26/agent-loop-model-tool-message-cycle/
2026-03-26T00:00:00+08:00
模型看一眼、决定下一步、系统执行，再把结果交回模型。真正的难点在消息演进和停止条件。
2026 年了，Agent 架构还要不要依赖大框架
https://v833.github.io/2026/03/21/agent-framework-reality/
2026-03-21T00:00:00+08:00
框架可以节省样板代码，却不能替你决定权限、状态、失败恢复和观测边界。先理解原理，再决定抽象层。
做 Agent 开发前，哪些大模型机制必须先懂
https://v833.github.io/2026/03/16/agent-llm-fundamentals/
2026-03-16T00:00:00+08:00
不需要先读完论文，但要理解 token、上下文窗口、reasoning、tool call 和 provider 差异，否则很多工程问题会被误判成 Prompt 问题。
六大支柱地图：为什么不同 Agent 产品仍然有共同骨架
https://v833.github.io/2026/03/11/agent-six-pillars-map/
2026-03-11T00:00:00+08:00
Claude Code、Cursor、Manus 看起来差异很大，但都在处理同一组问题：循环、工具、上下文、记忆、协作和 Harness。
Agent 应用如何启动：入口层与运行层为什么要分开
https://v833.github.io/2026/03/06/agent-bootstrap-and-runtime-boundary/
2026-03-06T00:00:00+08:00
用户只想看帮助时，不应该先加载模型、MCP 和终端 UI。启动边界决定了速度、可测试性和故障半径。
从聊天到执行：Agent 系统有哪些核心层次
https://v833.github.io/2026/03/01/agent-architecture-from-chat-to-action/
2026-03-01T00:00:00+08:00
先不急着选框架，沿着一次读取文件的请求，认识入口、上下文、Loop、工具、状态、界面和观测七层边界。