Foundations待学习
Agentic System 到底是什么
Agentic System 是围绕目标、状态、工具、反馈和终止条件运行的工程系统，不等于一个会聊天的模型。
节点解释图：concept-map
关键点
- Agent 不是模型人格，而是一套闭环：目标 → 上下文 → 动作 → 观察 → 修正 → 终止。
- 判断一个系统是否 agentic，要看它是否能基于反馈改变下一步，而不是看它用了多大的模型。
- 工程上要先定义可验证目标，再决定是否需要 agent。
深入解释
如果流程完全固定、输入输出可枚举，workflow 通常更可靠。
如果任务开放、多工具、状态不确定、需要探索或修正，才值得引入 agentic loop。
Agentic engineering 的核心不是“更聪明”，而是让不确定执行变得可观察、可控、可回归。
实践任务
把你当前的 AI RSS Digest 写成：目标、状态、工具、观察、终止条件五栏。
交付物：一张五栏表，说明这个系统哪些部分是 workflow，哪些部分可能是 agent。
验收标准
- 能说明 agent 和 LLM app 的区别
- 能指出至少两个不该 agent 化的环节
- 能写出一个可验证终止条件
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
LLM App 和 Agent 最大差异是什么？
LLM App 常是一次性输入输出；Agentic System 有状态、工具、副作用和反馈修正。
用了 tool calling 就是 agent 吗？
不一定。Tool calling 是能力，agent 还需要目标、策略、观察、验证和终止条件。
为什么先问“是否需要 agent”？
因为 agent 增加不确定性、成本和安全面；如果 workflow 能解决，workflow 往往更稳定。
Foundations待学习
Workflow vs Agent：什么时候不要用 Agent
固定路径优先 workflow，开放探索才考虑 agent；这是成本、可靠性和安全性的第一道判断。
节点解释图：decision-tree
关键点
- Workflow：路径固定、状态少、可测试性强。
- Agent：路径动态、能根据观察调整策略。
- Human-in-the-loop 不是失败，而是高风险动作的设计边界。
深入解释
把 agent 用在确定性任务上，会把简单问题变成概率问题。
把 workflow 用在开放探索任务上，会导致规则爆炸和脆弱分支。
好的系统通常是 workflow + 局部 agent，而不是全盘 agent。
实践任务
给“生成每日摘要、筛选高价值条目、深入追问、生成图示”分别选择 workflow/agent/human。
交付物：一张自动化层级表。
验收标准
前置/关联
无硬性前置，可从这里开始。
状态机：让 Agent 可恢复
敢于反问：问题与答案
agent 越多越好吗？
不是。agent 是处理不确定性的工具，不是架构装饰。
固定 prompt 链算 agent 吗？
多数情况下更像 workflow，除非它能根据观察动态改变路径。
如果一个需求能写成状态机，还需要 agent 吗？
未必。状态机能覆盖的确定性部分应优先状态机，agent 可处理异常和开放判断。
Foundations待学习
任务边界、成功标准、退出条件
没有明确边界的 agent 会无限探索、过度执行或沉默失败。
节点解释图：spec-card
关键点
- 任务规格至少包含输入、输出、约束、权限、成功标准、退出条件。
- 成功标准要可验证，不要只写“做好一点”。
- 退出条件包括完成、失败、等待人工、成本上限。
深入解释
Agent 的很多失败来自目标含糊：它不知道何时停止，也不知道什么证据算完成。
把验收条件写成断言，是从 prompt 走向工程的关键。
实践任务
为“节点问答助手”写 8 条验收标准和 4 条停止条件。
交付物：验收标准清单。
验收标准
- 至少包含安全边界
- 至少包含格式约束
- 至少包含成本/时间上限
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
为什么不是让模型自己判断完成？
模型可以辅助判断，但工程系统需要外部可审计标准。
如果成功标准写不出来，意味着什么？
可能需求还没澄清，或任务不适合自动化。
Foundations待学习
Context Engineering：上下文工程
上下文工程决定 agent 看到什么、忘掉什么、如何压缩和如何防污染。
节点解释图：context-stack
关键点
- Context 不是 prompt 文案，而是任务状态、约束、记忆、检索结果、工具观察的组合。
- 上下文过少会瞎猜，过多会稀释注意力。
- 上下文必须区分事实、偏好、临时状态和工具证据。
深入解释
Context Engineering 的关键问题：哪些内容在当前任务必要？哪些会过期？哪些可能污染？
高质量 agent 常把上下文拆成系统规则、任务卡、状态、证据和下一步，而不是一坨聊天记录。
实践任务
把一次长需求压缩成 10 行任务上下文，标出事实/假设/证据。
交付物：10 行 context card。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
prompt engineering 和 context engineering 区别？
前者偏表达和指令，后者偏信息选择、状态建模和检索注入。
为什么上下文不是越多越好？
因为 token 有成本，且无关信息会让模型注意力漂移。
Knowledge待学习
RAG / Wiki / Memory 的差异
RAG、Wiki、Memory 都和知识有关，但生命周期、写入方式、可信边界完全不同。
节点解释图：comparison-matrix
关键点
- RAG 是运行时检索：针对当前问题，从外部语料取证据。
- Wiki 是稳定知识沉淀：人或流程维护的结构化知识资产。
- Memory 是跨会话少量注入：偏好、稳定事实、长期约定，而不是资料库。
- 文件系统/Markdown 适合 Wiki/Skill，因为可审查、可 diff、可版本化；RAG 适合查询时取证据，不适合无脑承载所有记忆。
深入解释
一个有审视能力的问题是：为什么记忆不用 RAG 做，而采用 md 文件等文件系统实现？答案不是绝对的。RAG 可以检索记忆，但写入与治理才是关键：长期记忆需要可读、可删、可审计、可迁移，Markdown/文件系统天然支持 review 与版本控制；向量库更适合召回，不适合判断什么应该被永久保存。
Wiki 和 Memory 的区别在于使用方式：Wiki 是用户主动查阅或 agent 检索的知识库；Memory 是默认注入到每次会话的高影响事实，所以必须更克制。
RAG 的风险是召回错误或过期资料；Memory 的风险是污染所有未来会话；Wiki 的风险是无人维护。
实践任务
把 12 条信息分类为 RAG source / Wiki note / Memory / 不保存，并写出理由。
交付物：一个四列表格，附每条信息的生命周期和风险。
验收标准
- 能说出三者写入门槛
- 能说出三者读取方式
- 能说出三者失败模式
- 能提出一个反问并回答
前置/关联
Context Engineering：上下文工程
Memory Hygiene：什么不该记检索设计：Chunk、Metadata、Rerank、Citation
敢于反问：问题与答案
RAG 能不能当 Memory？
可以作为 memory 的检索层，但不等于 memory。Memory 更关注保存准入、默认注入和长期影响。
为什么很多 skill/wiki 用 Markdown？
因为它可读、可 diff、可 code review、可迁移，适合程序化记忆和稳定知识治理。
Wiki 和 RAG 有什么关系？
Wiki 可以是 RAG 的语料来源之一；RAG 是读取机制，Wiki 是知识资产形态。
为什么不把所有聊天记录都塞进向量库？
因为可召回不代表该信任；聊天记录大量临时、错误、过期信息会污染答案。
什么时候 RAG 比 Memory 更适合？
资料变化快、内容多、问题相关性强且需要引用来源时。
Knowledge待学习
检索设计：Chunk、Metadata、Rerank、Citation
RAG 的质量主要来自语料治理、切分、元数据、重排和引用，而不是“接个向量库”。
节点解释图：retrieval-pipeline
关键点
- Chunk 要围绕语义边界，不是固定字数万能。
- Metadata 决定过滤能力：来源、时间、权限、主题、可信度。
- Citation 让答案可追溯，rerank 改善召回噪声。
深入解释
好的 RAG 回答应区分：检索证据、模型推理、仍需验证。
权限过滤必须在检索阶段做，不能只靠最后让模型别说。
实践任务
为 agentic engineering 学习资料设计 metadata schema。
交付物：metadata schema + 3 个查询例子。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
向量库是不是 RAG 的核心？
它只是召回工具之一，语料质量和引用链更关键。
如果检索结果互相冲突怎么办？
展示冲突来源，降低结论强度，要求进一步验证。
Knowledge待学习
Memory Hygiene：什么不该记
长期记忆是高权限上下文，保存越多不一定越聪明，可能越容易偏。
节点解释图：risk-map
关键点
- 偏好、稳定身份、长期约定适合 memory。
- 临时任务进度、一次性结果、会过期的链接不适合 memory。
- 流程方法应进 skill，不应写成命令式 memory。
深入解释
Memory 的写入应该像数据库迁移一样慎重，因为它会影响未来很多任务。
删除和更新能力与新增同样重要。
实践任务
审查 10 条候选记忆，决定 add/skip/skill/wiki/session。
交付物：记忆治理表。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
为什么任务完成记录不该进 memory？
因为很快过期，占用上下文并误导未来判断。
如果用户说“记住所有项目进展”怎么办？
应解释风险，建议用项目文档/session，而不是长期 memory。
Knowledge待学习
知识沉淀闭环：回答到 Wiki/Skill/Test
一次回答结束后，真正的复利来自把可复用部分沉淀为 wiki、skill 或 test。
节点解释图：knowledge-loop
关键点
- 稳定事实 → wiki。
- 可重复流程 → skill。
- 容易回归的行为 → test。
- 临时上下文 → session，不进长期层。
深入解释
工程化 agent 要能反问：这个输出是否值得未来复用？应该沉淀到哪里？
沉淀不是保存全文，而是提炼可验证知识。
实践任务
把一次 bug 修复经历拆成 wiki/skill/test/session 四类。
交付物：沉淀决策表。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
skill 和 wiki 的区别？
skill 是操作流程，wiki 是知识说明；skill 应包含触发条件、步骤、验证。
什么时候不要沉淀？
一次性、低价值、无法验证、即将过期的信息不要沉淀。
Implementation待学习
Agent 的实现载体：Skill、Subagent、CLI、Service
Agent 是行为模式，不是某个固定技术形态；skill、subagent、CLI、服务、队列任务都可能承载不同层级的 agent 行为。
节点解释图：carrier-map
关键点
- Skill 本身不是运行实体，更像程序化记忆/流程模板；它能塑造 agent 行为。
- Subagent 是独立上下文的执行实体，适合隔离、并行、评审。
- CLI agent、HTTP service、队列 worker、cron job 也可以承载 agent loop。
- 判断载体看四件事：独立目标、状态、工具、反馈循环。
深入解释
“agent 实现载体可以是 skill 吗？”这个问题要拆开：skill 不是 worker 进程，但它可以定义 agent 的策略、工具使用规范和验证步骤；真正执行它的是当前 agent 或 subagent。
“agent 实现载体可以是 subagent 吗？”可以。subagent 天然有隔离上下文和独立目标，适合研究、实现、评审等子任务。
不要把载体和职责混淆：同一个 subagent 可扮演 worker、reviewer、researcher；同一个 skill 可被多个 agent 调用。
实践任务
为一个“代码审查 agent”选择实现载体，并说明为什么不用另外三种载体。
交付物：载体选择矩阵。
验收标准
- 覆盖 skill
- 覆盖 subagent
- 覆盖 service/queue
- 包含反例
前置/关联
无硬性前置，可从这里开始。
Worker 的实现载体是什么Orchestrator-Worker 模式
敢于反问：问题与答案
Skill 是 agent 吗？
严格说不是。Skill 是可复用流程/知识，执行它的 agent 才是运行实体。
Subagent 是 worker 吗？
可以是，但不总是。它也可以是 reviewer、planner、researcher。
什么时候用 CLI agent？
需要独立工具链、长任务、代码仓库操作或外部进程隔离时。
如果 skill 不是运行实体，为什么感觉它像 agent？
因为它封装了策略和步骤，降低了当前 agent 的决策空间，但它不会自己执行。
载体选择的首要约束是什么？
副作用风险、上下文隔离、可验证性和运行时长。
Implementation待学习
Worker 的实现载体是什么
Worker 是被分派去完成可验证子任务的执行者；它可以是 LLM subagent，也可以是普通代码、队列消费者、tool handler 或 workflow step。
节点解释图：worker-implementation-carriers
关键点
- Worker 是角色，不是技术。
- Worker 可以是 subagent、函数、tool、queue job、systemd service、workflow step、人工执行者。
- Worker 不一定需要 LLM；确定性任务用代码 worker 更可靠。
- Worker 的输入应小而明确，输出应可验证。
深入解释
Orchestrator-worker 的关键是边界：orchestrator 负责拆分、调度、合并、验收；worker 负责执行局部任务。
如果 worker 是 subagent，要给它完整上下文和验收格式；如果 worker 是 queue job，要给它幂等 key 和状态表；如果 worker 是 tool handler，要定义 schema、副作用和错误码。
Worker 的实现载体由任务性质决定：推理密集 → subagent；IO/批处理 → queue job；纯计算 → function；外部副作用 → tool/service。
实践任务
把摘要系统拆成 6 个 worker，并分别选择 subagent/function/tool/queue job/workflow step。
交付物：worker 设计表。
验收标准
- 每个 worker 有输入输出
- 每个 worker 有验证方式
- 至少一个非 LLM worker
前置/关联
Agent 的实现载体：Skill、Subagent、CLI、Service
Tool Contract：Schema、副作用、幂等、验证状态机：让 Agent 可恢复
敢于反问：问题与答案
Worker 和 Tool 的区别？
Tool 是能力接口；worker 是承担任务的执行角色。一个 worker 可以调用多个 tool，tool handler 也可被当作 worker。
Worker 一定由 orchestrator 调用吗？
通常在编排模式中是，但也可以由队列、cron 或用户触发。
Workflow step 是 worker 吗？
可以把它看作确定性 worker，前提是有明确输入输出和完成状态。
为什么不要所有 worker 都用 subagent？
LLM worker 成本高且不确定；确定性任务用代码更快、更可测。
Implementation待学习
Orchestrator-Worker 模式
编排者拆分和验收，worker 执行边界清晰的子任务。
节点解释图：sequence-flow
关键点
- Orchestrator 不应该亲自做所有事。
- Worker 需要任务卡、上下文、输出格式。
- 合并与评审是 orchestrator 的职责。
深入解释
并行化只有在边界清晰时才安全。
Worker 的交付物必须能被独立验证。
实践任务
设计三路并行实现、测试、评审任务。
交付物：任务分派表。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
多 agent 什么时候值得？
任务可并行、需要独立评审、上下文过大时。
如果 orchestrator 自己能做完，为什么还要 worker？
为了隔离上下文、并行和独立评审，而不是为了形式。
Implementation待学习
Tool Contract：Schema、副作用、幂等、验证
工具是 agent 接触真实世界的边界，必须有契约。
节点解释图：tool-contract
关键点
- Schema 限制输入。
- 副作用要显式。
- 幂等 key 防重复。
- 工具结果要验证。
深入解释
最危险的 bug 往往不是模型说错，而是工具副作用没验证。
实践任务
为发送通知工具写 schema 和验证步骤。
交付物：工具契约。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
为什么工具调用后还要验证？
工具成功返回不等于外部世界真的达成目标。
如果工具不可验证怎么办？
降低权限、增加人工确认或改工具设计。
Implementation待学习
状态机：让 Agent 可恢复
状态机把不确定过程变成可观察、可恢复的节点。
节点解释图：state-machine
关键点
- pending/running/blocked/completed/failed/retry 是基础状态。
- 状态比聊天历史更可靠。
- 每次副作用都应落状态。
深入解释
状态机帮助处理刷新、重复提交、进程崩溃和重试。
实践任务
给图像生成任务设计状态表。
交付物：状态表 DDL。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
为什么不只靠前端禁用按钮？
刷新、重试、多请求仍会发生，必须在持久层防重。
状态越多越好吗？
不是。状态要覆盖恢复路径，过多会增加转移复杂度。
Implementation待学习
Handoff：任务交接协议
交接格式决定多 worker 协作是否丢上下文。
节点解释图：handoff-card
关键点
- 交接包含目标、已做、证据、风险、下一步。
- 不要让接手者猜历史。
深入解释
交接是压缩上下文的一种工程格式。
实践任务
写一份 worker 交接模板。
交付物：handoff 模板。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
handoff 和 summary 区别？
handoff 面向继续执行，summary 面向回顾。
交接信息太多怎么办？
保留决策和证据，链接到原始材料。
Reliability待学习
Reflection 与 Verification 的差异
Reflection 是自检思路，Verification 是外部证据；两者不能混用。
节点解释图：verification-ladder
关键点
- Reflection 可发现遗漏。
- Verification 要用测试、工具、事实来源。
- 自我感觉正确不是验证。
深入解释
高风险输出必须有外部验证。
实践任务
把一次代码修改设计成 reflection checklist + verification commands。
交付物：双层验证清单。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
让模型检查自己有用吗？
有用但有限，不能替代测试和真实工具结果。
什么时候 reflection 会有害？
无限自我对话、没有外部证据、引入新幻觉时。
Reliability待学习
Eval：从 Demo 到回归测试
Agentic 系统不能只靠演示，需要任务集、评分和回归门禁。
节点解释图：eval-dashboard
关键点
- Eval set 覆盖常见、边界、故障任务。
- 评分可以是规则、LLM judge、人审混合。
- 每次改动都应跑关键回归。
深入解释
没有 eval 的 agent 很难长期迭代。
实践任务
为学习问答功能写 5 个 eval case。
交付物：eval 表。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
LLM judge 靠谱吗？
适合辅助，但关键场景要规则或人审抽检。
demo 很好为什么还要 eval？
demo 是样本，eval 是分布和回归保障。
Reliability待学习
Observability：日志、Trace、证据链
可观测性让 agent 的失败能被复盘，而不是只看到一句失败。
节点解释图：trace-map
关键点
- 记录输入、工具、输出、耗时、错误、成本。
- trace id 串起多 worker。
- 用户可读证据比原始日志更重要。
深入解释
没有证据链就无法判断是模型错、工具错还是上下文错。
实践任务
为聊天问答设计 trace 字段。
交付物：trace schema。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
日志越详细越好吗？
不是，要避免泄密和噪音。
用户要不要看到 trace？
通常看到摘要证据和错误解释，内部 trace 留给调试。
Reliability待学习
失败恢复：重试、降级、人工介入
真实 agent 必然失败，区别在于能否安全恢复。
节点解释图：failure-tree
关键点
- 重试要有上限和退避。
- 降级路径比沉默失败好。
- 高风险失败转人工。
深入解释
失败恢复策略应按错误类型区分：网络、权限、格式、语义、外部系统。
实践任务
给 imagegen 失败设计三层 fallback。
交付物：恢复策略表。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
所有失败都重试可以吗？
不可以。权限错误和输入错误重试只会放大问题。
失败时最少要留下什么？
错误类型、输入摘要、已完成副作用、下一步建议。
Operations待学习
成本、延迟与模型路由
Agentic 系统要把 token、工具耗时和模型选择当作产品约束。
节点解释图：routing-map
关键点
- 不同步骤可用不同模型。
- 缓存和批处理能显著降成本。
- 慢任务应异步化。
深入解释
成本控制不是上线后再说，而是设计时决定路径。
实践任务
给节点问答设计模型路由策略。
交付物：路由表。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
最强模型一直用就好吗？
不一定。分类、格式化、检索可用小模型或规则。
用户感知延迟如何控制？
loading、异步状态、局部更新、可取消。
Safety待学习
Human-in-the-loop：何时必须确认
人工确认是安全设计，不是自动化失败。
节点解释图：risk-gate
关键点
- 删除、支付、发布、外发、高权限操作要确认。
- 确认界面要展示将发生的副作用。
深入解释
HITL 的核心是把不可逆动作停在边界前。
实践任务
列出当前系统 5 个需确认动作。
交付物：确认点清单。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
所有动作都确认会怎样？
用户疲劳，真正风险反而被忽视。
确认前要展示什么？
目标、对象、范围、不可逆风险、替代方案。
Safety待学习
权限边界与最小工具集
Agent 只能拿完成任务所需的最小权限。
节点解释图：permission-map
关键点
- 工具权限按任务分配。
- 读写分离。
- 跨用户/session/profile 隔离。
深入解释
权限过宽会让模型错误变成安全事故。
实践任务
为另一个用户使用 Hermes 设计权限边界。
交付物：权限矩阵。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
prompt 能限制权限吗？
不能替代系统级权限控制。
为什么工具集要少？
减少误用空间和审计复杂度。
Operations待学习
部署、队列、Cron、Systemd、回滚
Agentic 功能上线后就是运维问题：任务、队列、日志、回滚、健康检查。
节点解释图：deployment-topology
关键点
- 长任务不要阻塞请求。
- systemd/cron 适合周期任务。
- 队列适合异步工作。
- 回滚路径要提前准备。
深入解释
能跑一次不等于能长期运行。
实践任务
为批量节点图生成设计 systemd/queue 运行方式。
交付物：部署方案。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
为什么不用请求线程直接生成所有图？
慢、易超时、失败不可恢复。
什么时候用 cron，什么时候用 queue？
固定周期用 cron/timer；用户触发且耗时用 queue。
Operations待学习
产品反馈闭环：学习行为如何改进系统
学习系统要记录完成、卡点和问题类型，用来调整内容，而不是只展示内容。
节点解释图：feedback-loop
关键点
- 已学节点反映进度。
- 聊天问题反映困惑。
- 失败/跳过节点反映难度。
深入解释
指标应服务学习，不制造噪音。
实践任务
设计 5 个不侵犯隐私的学习指标。
交付物：指标表。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
要不要记录所有聊天？
要克制，至少明确用途和可删除。
指标如何反哺内容？
高频困惑变 FAQ，完成率低的节点加实践或图示。
Projects待学习
实战：构建节点式学习助手
本模块自身就是一个学习助手案例：知识图谱、进度、问答、图示、反馈。
节点解释图：product-map
关键点
- 节点图谱组织学习路径。
- 问答绑定节点上下文。
- 已学状态提供反馈。
深入解释
用产品本身解释产品，是最好的 工程案例。
实践任务
为本学习模块写一页 工程案例。
交付物：工程案例。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
为什么思维导图比按天课程更适合？
概念依赖不是线性日期，图谱能表达分支和回看。
如何避免学习助手泛泛回答？
聊天 prompt 必须绑定当前节点知识和 FAQ。
Projects待学习
实战：多 Agent 代码实现与评审
用 implementer、spec reviewer、quality reviewer 练习多 agent 协作。
节点解释图：multi-agent-review
关键点
- 实现和评审分离。
- 先 spec review，再 quality review。
- 每步有测试证据。
深入解释
多 agent 的价值来自独立视角和上下文隔离。
实践任务
设计一次三角色代码任务流程。
交付物：多 agent 流程卡。
验收标准
前置/关联
无硬性前置，可从这里开始。
暂无关联节点。
敢于反问：问题与答案
为什么评审也用 agent？
独立上下文能发现实现者忽略的问题，但仍需最终验证。
何时不要多 agent？
任务很小、边界不清、合并成本高时。
Learning待学习
主题 知识能力地图：Agent Harness 工程师
把 Agent 系统、Agent 平台、Agent 系统、Agent 系统、工程主题拆成可学习、可实践、可理解表达的能力簇。
关键点
- Model + Harness = Agent：Harness 负责模型之外的产品化工程。
- 高频关键词包括 Agent Loop、Tool Use、MCP、Memory、Subagent、Multi-Agent、Evaluation、Sandboxing、Prompt Cache、KV Cache、Context Engineering。
- 学习计划必须最终落成项目实践，而不是只背概念。
深入解释
工程职责可以归纳为六类：架构选型、上下文/记忆、工具与运行环境、规划/多 Agent、eval/benchmark、产品反馈与成本延迟优化。
知识表达要把每个词映射到可验证 artifact：代码、页面、指标、trace、测试、材料。
实践任务
把 6 张 主题 材料整理成能力矩阵，并标注你当前掌握程度。
交付物：知识能力矩阵 + 学习差距图。
验收标准
- 覆盖至少 10 个 核心主题
- 每个能力有项目实践或补齐计划
- 能说清模型层和 Harness 层边界
前置/关联
无硬性前置，可从这里开始。
实战：构建节点式学习助手实战：把 AI RSS Digest 拆成 Agentic System
敢于反问：问题与答案
为什么先做 能力图谱？
因为学习不是泛泛积累名词，而是反推工程主题和项目沉淀证据。
如果一个词只会解释不会实现，算掌握吗？
不算。至少要能在真实系统里指出它的位置、失败模式和验证方式。
Operations待学习
Prompt Cache / KV Cache 与 token 成本
Prompt Cache 和 KV Cache 是 Harness 成本/延迟优化的关键入口：稳定前缀、复用上下文、减少重复推理。
关键点
- 缓存命中依赖稳定上下文前缀和清晰 cache key。
- 缓存不是免费午餐：污染、过期和权限边界会导致错误复用。
- token、latency、throughput 要和模型路由一起设计。
深入解释
日常工程里常见优化是把 system prompt、工具说明、固定知识放入稳定前缀，把用户任务和新证据作为增量。
缓存指标至少记录 hit rate、saved tokens、added latency、stale/permission miss。
实践任务
给每日学习推送设计一个可缓存 prompt 前缀和 cache invalidation 规则。
交付物：缓存策略表。
验收标准
- 包含 cache key
- 包含失效条件
- 包含权限隔离
- 包含成本指标
前置/关联
Context Engineering：上下文工程
成本、延迟与模型路由
敢于反问：问题与答案
缓存会不会影响安全？
会。跨用户或跨任务复用上下文必须先做权限隔离和失效检查。
什么时候不该缓存？
上下文含高敏感、强时效、权限相关或容易污染后续任务的内容时。
Safety待学习
Sandboxing 与 Agent Runtime：Docker、文件、网络、进程
Agent 要操作终端、浏览器、代码仓库和企业系统时，Sandbox 决定它能否安全地做真实任务。
图片暂不可预览
节点解释图：sandbox-topology
关键点
- Sandbox policy 要定义文件挂载、网络访问、进程时间、密钥暴露和清理策略。
- Docker 只是载体，真正重要的是权限边界和审计。
- 高风险动作必须和 Human-in-the-loop、trace、回滚机制结合。
深入解释
Agent 系统/Agent 平台 主题 中的 Docker、浏览器操控、终端、代码环境，本质都是 Tool-use Environment。Harness 要保证环境稳定、可控、可观察。
实践任务
为一个 coding agent 设计 Docker sandbox：可读写目录、网络白名单、超时、日志、清理。
交付物：Sandbox policy 文档。
验收标准
前置/关联
权限边界与最小工具集
部署、队列、Cron、Systemd、回滚Human-in-the-loop：何时必须确认
敢于反问：问题与答案
Docker 等于安全吗？
不等于。还要限制网络、挂载、用户权限、密钥和资源。
为什么 Sandbox 是 Harness 主题？
因为它决定模型动作如何进入真实环境，并限制错误动作的伤害范围。
Implementation待学习
Browser / Computer Use：真实环境操作
浏览器、终端、桌面和企业系统操作让 Agent 真正进入工作流，也带来等待、断言、页面变化和权限风险。
图片暂不可预览
节点解释图：browser-agent-loop
关键点
- Playwright/Claw 类工具需要显式等待条件和结果断言。
- 材料、DOM、日志和网络请求都是观察证据。
- UI 自动化失败通常来自选择器漂移、异步加载、登录态和权限边界。
深入解释
主题里提到浏览器操控和真实用户任务，重点不是会点按钮，而是把观察、动作、验证和恢复写成协议。
实践任务
为一个网页登录并抓取页面的 Agent 写 Observe/Act/Assert 步骤。
交付物：Browser task spec。
验收标准
- 有等待条件
- 有失败恢复
- 有材料或 DOM 证据
- 不保存敏感登录信息
前置/关联
Tool Contract：Schema、副作用、幂等、验证
Sandboxing 与 Agent Runtime：Docker、文件、网络、进程
敢于反问：问题与答案
UI 自动化为什么比 API 更脆弱？
因为页面结构、异步状态和用户态变化更多，必须有更强断言和恢复。
如果页面变化导致失败怎么办？
保留材料/DOM 证据，降级为人工确认或更新选择器，并加入回归用例。
Research待学习
Trace / MCTS / Agentic RL：策略搜索与在线优化
顶尖应届 主题中的 Trace 搜索、MCTS 工作流搜索、Agentic RL，核心是让 Agent 的尝试路径可记录、可评分、可优化。
图片暂不可预览
节点解释图：search-tree
关键点
- Trace 把每次计划、动作、观察、评分串成可分析轨迹。
- MCTS/搜索适合开放策略空间，但必须有 reward/eval 才能剪枝。
- Agentic RL 前提是任务环境、反馈信号和安全约束足够清晰。
深入解释
工程上先做 trace 和 eval，再谈搜索和 RL；没有评分函数的搜索只会扩大成本。
Reward 需要防止 reward hacking，关键任务要有人审或规则约束。
实践任务
选择一个失败任务，画出 3 条候选修复 trace，并定义评分标准。
交付物：Trace search 练习表。
验收标准
- 包含候选路径
- 包含 reward/score
- 包含剪枝理由
- 包含安全边界
前置/关联
Eval：从 Demo 到回归测试Observability：日志、Trace、证据链
失败恢复：重试、降级、人工介入
敢于反问：问题与答案
为什么不是一上来做 RL？
因为没有可靠环境、trace 和 eval，RL 会优化错误目标。
MCTS 在 Agent 里解决什么？
在多步决策空间中探索候选行动路径，并用评分选择更可能成功的路线。
Operations待学习
线上 Agent 指标：solve rate、latency、cost、trust
产品级 Harness 要关心任务成功率、completion quality、latency、token cost、user trust、recoverability 和安全边界。
图片暂不可预览
节点解释图：metrics-dashboard
关键点
- 离线 benchmark 只能说明一部分，线上 trace 和用户反馈才暴露真实任务分布。
- 指标必须能指导改进：是上下文问题、工具问题、模型问题还是产品交互问题。
- 成本和质量要一起看，不能只追求最强模型。
深入解释
Agent 系统/Agent 系统 主题 明确要求量化 Harness 改动对成功率、token 成本、延迟和质量的影响。
实践任务
设计一个 Agent Harness dashboard，列出 8 个指标和每个指标对应的改进动作。
交付物：指标看板草案。
验收标准
- 包含成功率
- 包含延迟
- 包含成本
- 包含恢复率
- 包含用户信任/满意度信号
前置/关联
Observability：日志、Trace、证据链
Eval：从 Demo 到回归测试产品反馈闭环：学习行为如何改进系统
敢于反问：问题与答案
为什么 completion quality 不等于 solve rate？
前者看输出质量，后者看任务是否真正完成；漂亮回答可能没有完成真实任务。
指标太多怎么办？
保留能驱动决策的指标，把原始日志留给调试。
Learning待学习
项目实践：Agent Harness 工程案例
最终目标是形成能写进学习记录、能讲解讲清楚的 Harness 项目，而不是零散知识点。
图片暂不可预览
节点解释图：case-study-board
关键点
- 工程案例 要包含问题、架构、数据流、关键权衡、失败恢复、eval、指标、材料和复盘。
- 每个 核心主题都要有项目里的落点。
- 最好基于真实系统：AI Digest 学习教练、文章学习平台、多 Agent 代码评审、沙箱 coding agent。
深入解释
理解表达不是罗列技术，而是讲你如何把模型能力变成可靠产品，以及如何用指标证明改动有效。
实践任务
为当前 Infinitetoken 学习模块写一页 工程案例 草稿。
交付物：一页项目沉淀文档。
验收标准
- 包含架构图
- 包含指标
- 包含失败处理
- 包含可访问页面或材料
- 映射至少 8 个 主题关键词
前置/关联
主题 知识能力地图：Agent Harness 工程师
实战：把 AI RSS Digest 拆成 Agentic System线上 Agent 指标：solve rate、latency、cost、trust
敢于反问：问题与答案
没有业界经历怎么掌握能力？
用真实可运行项目、公开页面、测试、trace、指标和复盘证明。
学习记录里该写“学过 MCP”吗？
最好写“实现/接入/设计了什么 MCP/工具协议，解决了什么问题，有什么指标”。