Agent 开发工程师从入门到高级的学习与实战成长路线

一个能够回答问题的聊天窗口，距离一个能够可靠完成任务的 Agent 系统，还有多远？

中间隔着工具调用、数据权限、状态管理、失败恢复、效果评测，以及持续运行时的成本和维护问题。Agent 开发工程师的成长，也可以沿着这条链路展开：先理解模型如何参与程序，再让它使用工具完成有限任务，最终能够为真实业务交付可观测、可控制、可迭代的系统。

这篇文章面向准备进入 AI 应用开发的程序员，也适合已经做过聊天机器人、希望继续进阶的开发者。我们用一个逐步升级的“企业知识库与工单助手”贯穿各阶段，把学习内容对应到可以交付的项目和可以验证的能力。前半部分解释各阶段应掌握的知识，后半部分给出六周基础准备、二十四周逐周任务，以及第 25 至 52 周的高级实践安排。每个周期都列出要做的事情、交付物和验收要求，可以直接作为个人学习计划使用。

优先建立模型调用、工具执行和评测的完整闭环，再根据任务需要引入检索、持久化和多 Agent 协作。 技术栈可以更换，这些能力会持续影响项目质量。

一 Agent 开发工程师需要承担什么工作

在实际项目里，Agent 开发通常涉及四类职责：把业务需求转成可验证的任务，给模型提供合适的数据和工具，约束执行过程，以及根据真实结果持续改进。

例如，用户提出“根据报销制度解释这笔申请被拒绝的原因，并帮我准备申诉工单”。系统需要找到正确版本的制度，读取该用户有权限查看的申请，判断证据是否充分，生成工单草稿，并在获得相应授权后提交。任何一步出错，都可能让流畅的回答失去实际价值。

理解下面几个概念，有助于判断每一步需要什么设计：

概念	解决的问题	示例
大模型应用	利用模型理解或生成内容	将一段报销说明转换为结构化字段
RAG 检索增强生成	在回答前取回相关资料	检索对应版本的报销制度并引用来源
工作流	用预先定义的路径组织步骤	校验申请、查询制度、生成草稿、人工确认
Agent	让模型根据环境反馈动态选择下一步	查询后发现缺少附件，继续查找附件记录

这些方式可以组合使用。RAG 可以作为 Agent 的一个工具，Agent 也可以作为固定工作流中的一个节点。Anthropic 的架构讨论将工作流与 Agent 的区别放在控制路径上：前者由代码预先定义，后者允许模型动态组织过程与工具使用。Building effective agents

判断是否需要 Agent，可以先问：任务下一步是否真的依赖运行时获得的信息？如果规则明确、路径固定，一个普通程序或工作流往往更容易验证和维护。

二 先看完整成长路线

下面是一种以交付能力划分阶段的学习安排。各阶段可以交叉推进，例如第一次接入模型时就应开始记录失败案例，第一次接入工具时就应校验权限。

阶段	核心能力	知识库与工单助手的阶段产物	进入下一阶段的标志
基础准备	编程、HTTP、数据库、测试	不使用模型的工单查询 API	能独立定位接口错误并完成部署
模型应用入门	模型调用、提示词、结构化输出	问题分类与工单摘要服务	能处理错误、超时和不合法输出
单个 Agent	工具设计、执行循环、终止条件	可以自主选择只读查询工具的助手	能解释一次任务的每步执行结果
数据与上下文	RAG、权限过滤、上下文与记忆	带来源引用的企业知识库助手	能区分检索失败与生成失败
复杂任务工程	状态机、持久化、人工审批	可暂停恢复的工单处理流程	中断恢复不会重复产生业务副作用
生产系统	评测、监控、安全、成本管理	有发布门槛和回退机制的服务	能用证据说明版本变化带来的影响
高级进阶	架构取舍、平台能力、业务优化	可复用的运行与治理能力	能指导团队解决一类任务的共性问题

初级工程师应当能够在明确边界内完成一个功能；中级工程师需要独立负责完整链路；高级工程师还要判断哪些问题值得做、架构复杂度是否合理，以及团队如何持续交付。

三 基础准备 掌握构建服务的基本能力

选一门主力语言并写出完整服务

对于没有明显技术栈偏好的学习者，可以用 Python 作为主线，减少在模型实验和数据处理之间切换的成本。如果已经熟悉 TypeScript、Java 或 Go，也可以沿用现有语言，先完成同样的工程闭环，再按需要补充 Python。

开始阶段需要掌握函数、模块、异常处理、类型约束、文件读写、异步 I/O 和依赖管理。学习异步编程时，要能解释一个请求何时被取消、超时如何传递、并发任务如何限制数量。Agent 会频繁等待外部模型和工具，资源管理问题很快就会出现。

服务端基础至少应覆盖 HTTP 请求与响应、身份认证、参数验证、SQL、事务、日志和配置管理。Git、自动化测试、容器部署也应在第一个项目里用起来。

实战任务与验收

先实现一个普通工单服务：支持创建工单、按 ID 查询、更新状态，以及按当前登录用户过滤结果。使用数据库保存数据，通过测试覆盖正常路径、参数错误和越权访问。

完成后，尝试主动制造三个问题：数据库暂时不可用、请求中途取消、客户端重复发送创建请求。能够说明系统的行为、日志位置和修复方式，才说明你具备了后续接入 Agent 的基础。

这一阶段不必从训练大模型开始。先理解后续会遇到的 token、向量相似度、概率和统计指标；涉及模型训练或研究时，再深入线性代数、优化和深度学习。

四 入门阶段 让模型成为可测试的程序组件

理解模型调用的边界

第一次接入模型，建议直接使用模型服务的原生 SDK 或 HTTP 接口。先看清请求中包含什么、返回中包含什么，以及失败时能拿到什么信息，再引入封装框架。

重点理解上下文窗口、输入输出 token、流式响应、采样参数和结束原因。模型能接收较长输入，并不意味着每次都应该把所有历史记录传进去；降低随机性也不能替代业务校验或保证重复调用得到完全相同的结果。

提示词需要写清任务、输入含义、输出结构和缺少信息时的处理方式。例如，分类工单时，应规定允许的分类、无法判断时的返回值，以及摘要应保留哪些事实。

把输出当作外部输入处理

假设模型要返回以下内容：

{
  "category": "expense",
  "summary": "申请人希望确认差旅报销被拒绝的原因",
  "needs_clarification": true
}

程序仍需要验证字段类型、分类枚举、长度和必填项。即使输出符合 JSON Schema，也只能说明结构符合约定，不能证明摘要准确或分类正确。

在模型支持时使用结构化输出，同时在服务端保留验证。失败后采用有上限的修正重试，仍无法得到合法结果时返回明确状态，交给用户补充信息或转人工处理。

实战任务与验收

给工单服务增加分类与摘要功能。准备至少二十条人工标注样本，包含正常描述、信息不足、混合诉求、超长输入和诱导模型忽略规则的内容。

验收时检查三件事：结果能否被程序稳定解析；失败是否有明确处理路径；是否记录模型标识、提示词版本、耗时和用量。日志中涉及个人信息或业务内容的字段，应按需要脱敏和限制访问。

这二十条样本只是起步用的回归集。随着场景扩大，需要继续补充覆盖，不能用一小组样本推断整个业务的可靠性。

五 初级阶段 从工具调用到单个 Agent

工具是有契约的业务接口

先给助手提供两个只读工具：查询工单状态、检索制度资料。每个工具都应写明用途、输入参数、返回结构、错误类型和访问边界。

例如，查询工单工具可以接受 ticket_id，但当前用户身份和租户信息应由后端从认证上下文注入。模型提供的用户 ID 或“管理员”声明不能成为授权依据。

工具返回“未找到”“权限不足”“服务超时”时，Agent 应有不同处理方式。把所有异常都转成一句“查询失败”，会让模型无法判断应该补充信息、停止任务还是稍后重试。

理解 Agent 执行循环

单个 Agent 的基本执行过程可以写成下面的伪代码：

初始化任务状态、权限上下文和执行预算
循环直到达到步数、时间或费用上限
    调用模型，传入任务、必要上下文和可用工具定义
    如果模型给出最终答案
        校验业务输出并结束
    如果模型请求工具
        校验工具名称、参数、权限和剩余预算
        按工具策略执行，记录结果并更新上下文
    否则
        返回明确的失败状态
达到上限后保存当前状态，并说明未完成的部分

这段伪代码只展示控制结构。真正实现时，还需要处理单次模型和工具调用的超时、取消、部分失败，以及多个工具调用之间的依赖。

不要把无限重试当作自我修复。参数错误可以根据错误信息修正；权限不足通常应停止或请求授权；写入操作超时可能意味着结果未知，需要先查询执行结果。

实战任务与验收

让用户提出“我的报销申请为什么还没处理完”。助手能够判断是否需要询问工单编号，查询状态，再查阅相关制度，并结合证据回答。

验收时应覆盖工具参数错误、查无记录、权限不足、工具超时和反复调用同一工具。每种情况都应在有限时间内结束，执行记录能够还原工具名称、参数摘要、结果状态和停止原因。

此时再学习 Agent 框架会更有针对性：你能判断它帮助管理的是消息、工具、状态还是执行过程，也能在框架之外定位问题。

六 中级阶段 处理知识检索与上下文

建立可检查的 RAG 链路

知识库助手的难点之一，是找到当前用户能够访问、并且确实适用于问题的资料。一个可检查的检索链路包括：

资料解析 → 分块与元数据 → 索引
用户问题 → 权限过滤与检索 → 必要的重排 → 证据组装 → 回答与引用

分块时保留标题、文档 ID、版本、生效时间和来源位置。权限过滤应在内容进入模型前生效；不要先检索出无权访问的正文，再要求模型“不要泄露”。缓存和日志也应遵守相同边界。

先建立简单检索基线，再根据失败样本决定是否增加关键词与向量混合检索、查询改写或重排。例如，精确的工单编号和错误码，与语义相近的制度问题，需要的检索方式可能不同。

把检索质量和回答质量分开评估

准备一组问题，并为每个问题标注相关文档或证据片段。先检查正确证据是否进入候选结果，再检查模型是否正确使用证据。

观察到的现象	优先检查的位置
正确资料根本不在索引里	采集、解析、更新与入库流程
资料已入库但没有被检索到	分块、检索条件、索引和排序
正确资料进入候选却没进入最终上下文	重排、截断和上下文预算
上下文已有正确证据但回答错误	提示词、模型能力和任务定义
答案合理但引用不支持结论	引用生成、证据绑定和回答校验

没有证据时，应说明缺少依据并请求补充。两个版本的制度冲突时，应结合生效时间和适用范围处理，必要时交由人工确认。

区分工作状态与长期记忆

当前任务的工具结果、待确认草稿和执行进度，可以放在会话或任务状态中。跨会话保留的偏好和业务事实，需要明确写入条件、来源、更新时间、适用范围与删除机制。

摘要也可能丢失信息。涉及审批金额、授权范围和操作目标时，应保留可校验的结构化字段，不要只依赖一段自然语言摘要。

以 LangGraph 为例，其持久化文档将线程内的检查点与跨线程存储区分开，分别用于运行状态和应用定义的长期信息。学习框架时应理解这类职责划分，再选择存储方案。LangGraph Persistence

实战任务与验收

让知识库包含新旧制度、相似条款和受限文档。构建一组覆盖这些情况的问答样本，输出检索命中情况、回答正确性和引用支持情况。

用户无权访问的内容不应进入模型上下文；旧制度不应被无条件用于新申请；缺少资料的问题不应生成确定结论。能分别定位这几类失败，才算建立了可迭代的知识库能力。

七 中高级阶段 让复杂任务可以暂停和恢复

用状态机表达业务过程

当助手开始创建或修改工单，就需要明确任务状态。例如：

待处理 → 查询资料 → 生成草稿 → 等待确认 → 提交中 → 已完成
                         │                  │
                         └→ 已取消          └→ 结果待核实

“结果待核实”很有必要：网络超时可能发生在工单已经创建、但响应尚未返回时。直接重试可能产生重复工单，把它标记为“提交失败”也可能误导用户。

保存任务状态、工具调用标识、关键输入和外部业务 ID。恢复任务时，先确认哪些步骤已经产生结果，再决定继续执行哪一步。

把幂等与审批落实在执行层

写入工具可以使用稳定的业务操作键，并在服务端通过唯一约束或幂等记录控制重复执行。外部系统不支持幂等时，需要通过结果查询、操作台账或人工核查处理不确定状态。保存检查点本身不能保证外部副作用只发生一次。

人工确认应绑定具体操作，例如工单标题、提交对象和附件列表。如果这些内容发生变化，应重新确认，而不是复用一条笼统的“同意”。

在需要时学习 MCP

MCP 可以作为连接模型应用与外部工具、资源的协议层，适合需要在多个客户端复用能力的场景。学习重点是客户端与服务端职责、能力发现、输入输出契约，以及相应部署方式下的身份与权限处理。

MCP 解决连接协议问题，业务工作流、模型选择和上下文管理仍需要应用设计。工具接入后，也应继续在服务端校验权限。MCP Architecture overview

实战任务与验收

让助手生成工单草稿，等待用户确认后提交。分别在等待确认、外部提交成功但本地尚未记录、提交响应超时等位置模拟中断。

验收重点是：恢复后是否保留正确状态，重复请求是否产生重复工单，用户是否能取消尚未执行的任务，以及结果不确定时是否进入核查流程。

八 生产阶段 用评测和运行数据管理质量

建立任务级评测

评测需要检查任务是否完成，以及执行过程是否遵守约束。例如，“回答已创建工单”不能作为创建成功的依据；应该查询测试环境，确认目标用户下是否存在内容正确且唯一的工单。

建议将评测分成三层：确定性的参数、权限和工具测试；完整任务的端到端评测；对表达质量和复杂判断进行人工抽样。使用模型评分时，应以人工标注校准评分标准，避免只因为回答流畅就获得高分。

固定保留一组回归样本，并从线上失败中补充新样本。评测时记录数据集、模型、提示词和工具版本；对波动明显的任务重复运行，报告样本数量与结果分布。探索时使用的样本，也应与最终比较版本效果的保留集区分开。

Anthropic 的 Agent 评测指南强调，除了最终输出，还需要结合执行轨迹与环境中的实际结果判断任务完成情况。Demystifying evals for AI agents

观察效果 延迟和成本

生产监控至少应能回答：用户是否完成任务，哪里最容易失败，多少任务需要转人工，一次任务需要多少时间和费用。

指标	用途
按任务类型统计的成功率	避免简单任务掩盖复杂任务的问题
越权与错误写入事件	发现业务边界失效
工具错误率和重试次数	定位外部依赖与接口设计问题
P50 和 P95 总耗时	同时观察常见体验与长尾等待
每个成功任务的成本	将失败重试和工具费用计入投入
人工接管率与接管原因	判断自动化覆盖范围是否合理

成本优化可以从缩减无用上下文、缓存适合复用的结果、限制循环和按任务路由模型开始。每次优化都应比较质量变化；调用价格下降但失败率升高，可能让完成同一任务的总成本增加。

让安全控制成为系统能力

网页、附件和检索结果都可能包含试图改变系统行为的指令。应把它们视为待处理数据，并通过工具白名单、权限校验、网络与文件访问限制、沙箱和必要审批约束操作。

提示词可以表达规则，执行层必须落实规则。测试集应覆盖恶意文档要求读取秘密、跨租户检索、伪造管理员身份和诱导重复提交等情况。

发布时将提示词、模型配置和工具定义一起版本化。先运行离线回归，再通过小范围流量观察实际表现；保留停用高风险工具、切回旧版本或转为只生成草稿的能力。

九 高级阶段 根据证据作架构取舍

多 Agent 协作

多 Agent 适合能够拆分、并行处理或独立复核的任务。例如，不同模块的代码分析可以分别进行，再由汇总节点整合结果。

引入之前应明确每个角色的输入输出、共享状态、失败处理与总体预算。比较时使用相同任务集和相近资源预算，观察它是否比单个 Agent 或固定工作流提高完成率。通信开销、重复检索和角色间矛盾也需要计入成本。

模型适配与微调

当失败来自缺少资料时，应先改善数据供给；来自工具不可靠时，应修复接口；来自任务规则模糊时，应澄清需求。稳定、重复且有高质量样本的行为偏差，才适合进一步评估微调等模型适配方式。

这一方向需要补充数据清洗、训练集与验证集划分、数据泄漏检查和模型评测。模型记住了训练样例，不代表它能够处理未见过的任务。

平台建设与团队协作

当多个业务反复需要模型接入、权限、评测、追踪和预算管理时，可以逐步抽取公共能力。先从真实项目中识别重复问题，再确定哪些部分值得统一。

高级工程师还需要把架构判断写成团队能使用的约定：何时允许自主执行，何时需要人工确认，如何定义任务成功，以及出现质量下降时由谁处理。

能够解释“这个业务为什么需要 Agent”“为什么采用这套执行结构”“什么证据支持扩大自动化范围”，比掌握更多框架名称更能体现高级能力。

十 第 1 至 24 周逐周学习与交付计划

下面按每周十到十五小时安排，围绕同一个项目持续开发。完成前二十四周的目标是独立交付一条可验证的 Agent 业务链路；第 25 至 52 周再进入架构、平台和真实业务改进。周数是排期参考，未通过验收时应延长当前阶段。

开始前确定学习入口

先尝试独立完成一个小测试：读取 JSON 文件，校验字段，保存到数据库，再通过 HTTP 返回查询结果，同时写一个正常测试和一个错误测试。如果无法独立完成，先走下面六周准备期；已有相应经验的开发者可以直接从第 1 周开始。

准备周期	本周必须完成的事情	交付与验收
准备第 1 周	配置 Python 环境和 Git；练习函数、列表、字典、模块；写一个命令行工单录入程序；提交代码并练习撤销自己的改动	从终端录入标题和内容并查询；空标题能被拒绝；能说明每个文件的作用
准备第 2 周	学习异常、类型标注、文件操作和依赖管理；把工单保存为 JSON；处理文件不存在和格式损坏	重启后数据仍在；损坏文件不会被静默覆盖；在新环境按说明运行成功
准备第 3 周	学习 HTTP 方法、状态码和请求体；实现创建、查询、更新三个接口；用命令行发送请求	正常、参数错误、记录不存在各有可重复的请求示例
准备第 4 周	学习 SQL、主键、索引、事务；将文件存储换成数据库；实现分页；用参数绑定执行查询	数据可持久化；分页顺序稳定；写入失败能回滚；解释一条查询使用的索引
准备第 5 周	学习异步等待、超时、任务取消；编写自动化测试；模拟数据库错误和外部接口超时	测试独立运行；超时后请求会结束；日志包含请求标识且不输出秘密
准备第 6 周	学习容器、环境变量和基础 CI；打包服务；配置自动测试；整理启动和排错说明	在干净环境部署；缺失配置时明确报错；修改导致测试失败时 CI 能发现

准备期结束后重新做入口测试。仍需要逐行照抄才能完成的部分，单独补练，不要同时叠加模型、向量数据库和 Agent 框架。

固定技术范围与每周工作节奏

为了控制学习变量，主线可以采用 Python、HTTP 服务、PostgreSQL、一个模型服务和一种持久化工作流实现。检索先使用一种索引方案，界面先使用简单表单或命令行。已经有成熟语言栈的读者可以替换实现，保留相同的交付要求。

在 docs/stack.md 记录实际选择的运行时、依赖版本、模型标识和配置。密钥通过环境变量或秘密管理设施提供；示例配置只保留变量名。第 1 至 6 周先用直接调用理解原理，第 7 周再评估是否引入框架，后续以完成业务任务为主，避免每周更换技术栈。

每周可以按下面的顺序安排，工作日与周末可根据个人时间调整：

时间	要完成的事情
第一天约 1 小时	阅读当周相关官方文档；写下要解决的问题和验收用例
第二天约 2 小时	完成最小实现，让正常路径运行起来
第三天约 2 小时	接入现有项目，补齐输入校验、状态与错误处理
第四天约 2 小时	构造异常、攻击或中断案例，记录实际行为
第五天约 1 小时	修复问题、运行回归、整理运行命令和结果
周末约 2 至 7 小时	完成集成演示、补充测试和周复盘；未通过验收则继续修复

每周固定提交一份 reports/week-NN.md，包含本周目标、代码位置、运行命令、验收结果、失败案例和下周遗留项。涉及模型实验时，附数据集版本、模型标识、提示词版本、样本数量、耗时和费用。这里记录工具输入输出与业务状态，不要求模型提供内部思维过程。

下文出现的样本数量是练习规模，用于避免只测试一两个成功例子。成功率、延迟和费用目标应在评测前结合场景写入验收文件；满足练习规模不等于达到生产可靠性要求。

第 1 周 明确业务范围并搭建项目

本周目标： 把“做一个企业助手”缩小成可以开发和验收的需求。

1. 写出三类用户任务：查询工单、解释制度、准备申诉草稿；分别列出输入、期望结果和不可执行的操作。
2. 创建项目目录，分开接口、业务逻辑、数据访问、模型适配、工具和测试；先不安装 Agent 框架。
3. 建立环境配置、数据库连接、健康检查接口和统一错误结构；给请求分配 request_id。
4. 准备两个租户、每个租户两个用户，以及相互隔离的工单示例数据；全部使用虚构信息。
5. 列出至少十个端到端场景，标明哪些需要模型，哪些只需要普通代码。

交付物： 需求说明、数据字典、项目骨架、示例配置、启动说明。

验收条件： 新环境能够启动并访问健康检查；缺少关键配置时服务启动失败并解释原因；每个计划功能都有具体输入和预期结果。说不清任务边界时，先缩小需求。

第 2 周 完成带权限控制的工单 API

本周目标： 给后续工具调用提供可靠业务接口。

1. 实现创建、查询、分页和状态更新；编写数据库迁移与种子数据脚本。
2. 从可信认证上下文获取用户和租户；建立对象归属校验，禁止通过请求参数切换身份。
3. 约束工单状态转换，例如已关闭工单不能被任意改回处理中；为写入操作使用事务。
4. 编写正常、参数错误、不存在、跨用户和跨租户访问测试。
5. 模拟数据库暂时不可用与写入中断，检查错误响应、回滚和日志。

交付物： 工单 API、迁移脚本、接口示例、权限测试与第一份集成报告。

验收条件： 授权用户完成 CRUD；越权请求不能读取或修改目标记录；事务失败后没有半成品数据。权限测试未通过，不进入工具接入阶段。

第 3 周 接入模型并掌握请求生命周期

本周目标： 看清一次模型调用如何开始、结束和失败。

1. 使用原生 SDK 或 HTTP 接入一个模型；保存脱敏的请求与响应示例，辨认文本、工具请求、用量和结束状态。
2. 实现工单摘要接口，限制输入长度与最大输出，配置单次超时和总请求期限。
3. 为限流、网络错误、认证失败和无内容响应设计不同处理路径；只对适合重试的错误做有限重试。
4. 增加流式输出演示，处理客户端断开和中途失败；用模拟服务验证取消能否传递。
5. 运行十条不同长度输入，统计耗时与用量；费用按实际价格配置计算，不把价格写死在业务代码中。

交付物： 模型适配器、摘要接口、流式演示、错误处理表和调用记录。

验收条件： 正常请求能完成；超时、取消和认证失败能明确结束；重试不会无限延长请求；日志不包含密钥。无法复现的外部错误用模拟测试补齐。

第 4 周 实现结构化分类并建立第一组回归样本

本周目标： 让模型输出可以被程序使用和验证。

1. 定义分类枚举、摘要长度和 needs_clarification 等字段；建立服务端 Schema 校验。
2. 编写提示词，说明任务、字段含义、信息不足和多重诉求的处理规则；保存版本。
3. 准备至少三十条人工标注样本，覆盖正常、缺信息、混合诉求、超长文本和恶意指令。
4. 实现不合法输出的有限修正和最终失败状态；禁止静默补造关键字段。
5. 比较两版提示词，分别统计结构合法率与业务正确率，人工复查改变结果的样本。

交付物： Schema、提示词版本、标注数据集、批量评测脚本和对比报告。

验收条件： 非法结构不会进入数据库；不确定问题能被识别或转入明确失败路径；每个分类错误都有记录。改进结论必须对应同一批样本和配置。

第 5 周 将业务能力封装成只读工具

本周目标： 设计模型能够正确调用、服务端能够可靠执行的工具。

1. 定义 get_ticket 和 search_policy，为每个工具写用途、参数、输出和错误码；制度检索暂时使用小型本地样例库。
2. 让模型选择工具并生成参数，工具实际执行由应用代码负责；身份信息由后端注入。
3. 校验工具名称、参数类型、字段范围和访问权限；拒绝未知工具及多余的危险参数。
4. 为查无记录、权限不足、服务超时和暂时不可用设计不同结果，避免混成一个字符串。
5. 分别编写工具单元测试和模型选择测试，确认故障来自参数生成还是工具执行。

交付物： 工具目录、工具契约、调用适配器和独立工具测试。

验收条件： 伪造身份、未知工具和非法参数均无法执行；工具能脱离模型直接测试；每个错误都能定位到工具及其调用标识。

第 6 周 手写单个 Agent 执行循环

本周目标： 理解模型决策、工具反馈和终止之间的关系。

1. 实现模型调用、工具执行、结果回填和最终响应的循环；为工具请求与结果保留关联 ID。
2. 增加最大轮数、总期限和费用预算；预算耗尽后返回未完成状态与已知事实。
3. 实现缺少工单编号时的追问；关键目标不明确时禁止随意选择记录。
4. 检测反复请求同一工具、空输出和未知协议状态，设计明确停止策略。
5. 跑通至少二十个任务，包含直接回答、一次查询、多次查询、补充信息和无法完成。

交付物： Agent 运行器、任务状态结构、完整调用记录与演示脚本。

验收条件： 每个任务都有成功、待补充、失败或预算终止等明确状态；故意让工具持续失败时也会结束；用户可查看已完成操作和未完成部分。

第 7 周 比较框架并稳定接口边界

本周目标： 确定后续实现方式，保留定位问题的能力。

1. 选择一个候选框架，用同样的两个工具重做第 6 周最小任务；只做局部验证，暂不整体迁移。
2. 对比消息与工具协议、流式事件、状态保存、取消、异常传播和测试难度。
3. 用同一组任务比较执行结果、代码复杂度和额外依赖；写出采用或不采用的理由。
4. 定义统一任务结果，包含 task_id、状态、最终输出、引用、工具摘要和错误分类。
5. 若采用框架，完成迁移并重跑原有回归；若保留自研循环，补齐已经发现的接口缺口。

交付物： 架构决策记录、固定的 Agent 接口、迁移结果或保留方案。

验收条件： 工具业务代码不依赖具体消息格式；能替换模拟模型做离线测试；第 6 周场景没有因迁移丢失。无法说明框架价值时，延后引入。

第 8 周 建立文档采集与解析管道

本周目标： 将资料变成带来源和权限信息的可检索数据。

1. 收集二十至三十份虚构制度资料，包含新旧版本、相似标题、表格和不同可见范围。
2. 先支持 Markdown 与文本，再增加一种能提取文字的 PDF；扫描件识别另设任务，不混入当前承诺。
3. 为文档生成稳定 ID，记录版本、生效日期、租户、访问范围、来源位置与内容指纹。
4. 按章节切分，并保存可读的分块预览；人工抽查标题、表格和跨页内容是否丢失。
5. 实现失败文档隔离与重复入库检测；同一份文档重复运行不会生成无意义副本。

交付物： 导入脚本、文档清单、分块文件、解析失败记录。

验收条件： 每个分块都能追溯到原文；权限元数据没有丢失；更新版本不会被误判为完全相同；无法解析的文件有明确记录。

第 9 周 建立检索基线和证据标注集

本周目标： 在生成答案之前，先证明能够找到正确资料。

1. 用当前样例库建立关键词检索基线，再实现一种向量检索；锁定 embedding 模型和索引配置。
2. 准备至少五十个问题，标注相关文档或证据片段，覆盖同义表达、编号、旧版本和无答案情况。
3. 在内容返回前应用租户与文档权限条件；检查检索调试接口也遵守同样限制。
4. 比较不同候选数量下的检索结果，计算“前 k 个结果是否包含所需证据”等指标，并明确分母。
5. 分类整理未命中原因：未入库、解析丢失、过滤错误、排序靠后或问题本身含糊。

交付物： 两种检索基线、证据标注集、检索报告与未命中列表。

验收条件： 能单独运行检索评测；受限内容不出现在无权用户的候选正文中；每个未命中样本可以追查处理环节。

第 10 周 实现带引用的 RAG 回答

本周目标： 让结论与证据建立可检查的关系。

1. 将候选片段整理为带来源 ID 的上下文，限制长度并保留标题、版本和位置。
2. 设计回答格式，要求关键结论引用来源；后端验证引用 ID 确实属于本次授权证据。
3. 实现无证据、证据不足和多版本冲突的响应方式；必要时追问生效时间和适用对象。
4. 人工标注答案是否正确、引用是否支持对应结论，以及是否加入未经支持的关键事实。
5. 将检索评测与回答评测分开输出，比较“检索成功但回答失败”和“检索已经失败”的比例。

交付物： RAG 接口、引用展示、答案标注规范与分层评测报告。

验收条件： 引用可打开或定位原文；伪造引用被发现；无答案样本不会被当作普通事实问题直接编造。格式正确不能替代引用内容审核。

第 11 周 完成检索优化与数据更新

本周目标： 根据失败原因改进，并保持索引与资料同步。

1. 从第 9、10 周选出主要失败类型，只选择一项优化，例如混合检索、重排或分块调整。
2. 在相同样本上比较优化前后效果、延迟和费用，记录改善与退化的样本。
3. 实现文档新增、更新、删除和重新索引；权限撤销时同步失效相关索引与缓存。
4. 将长对话中的任务目标、业务标识和确认字段结构化保存；比较截断与摘要对证据保留的影响。
5. 测试更换制度版本、删除文档和撤销权限后的新任务，确认旧答案与旧缓存不会继续被错误复用。

交付物： 一项有依据的检索改进、增量更新脚本、上下文管理方案。

验收条件： 报告可复现；已删除或无权资料不进入新的模型请求；关键确认字段不会因摘要而被改写。优化无收益时保留基线并记录原因。

第 12 周 把任务建模为显式工作流

本周目标： 为可暂停、可恢复的任务建立状态与接口。

1. 定义查询、草稿、等待确认、提交中、已完成、已取消、失败和结果待核实等状态及允许转换。
2. 定义任务表、步骤记录和外部操作记录；区分任务 ID、步骤 ID 与业务操作 ID。
3. 提供创建任务、查询状态和取消任务接口；长任务返回任务标识，不依赖单个 HTTP 连接一直存活。
4. 将模型生成草稿与实际提交分成不同节点，审批前只执行只读或草稿操作。
5. 对非法状态转换、重复启动和取消后继续执行编写测试。

交付物： 状态转换表、持久化结构、任务接口与工作流骨架。

验收条件： 任务状态由明确规则更新；已取消任务不会启动新的写入；每次状态转换都有可查询的记录和原因。

第 13 周 保存检查点并实现中断恢复

本周目标： 进程退出后能够继续任务，同时理解重放范围。

1. 在明确的节点边界持久化状态，包含输入版本、已获得的工具结果和下一步位置。
2. 将模型请求、外部读写等不确定操作与纯状态计算区分，确认框架或运行器恢复时会重放哪些代码。
3. 分别在模型调用前后、工具返回前后和等待确认时强制终止进程，再重启恢复。
4. 记录未完成步骤和已经持久化的步骤；旧检查点缺少字段时应拒绝恢复或经过受控迁移。
5. 检查恢复时是否重新确认身份及当前权限，防止恢复过期授权。

交付物： 检查点存储、恢复入口、中断位置与重放行为报告。

验收条件： 只读任务可从检查点继续；无法确定外部操作结果时不会假定成功或随意重做；恢复任务仍遵守当前权限。

第 14 周 实现绑定具体内容的人工确认

本周目标： 把授权落实为可核查的业务动作。

1. 展示待提交的标题、对象、内容和附件列表；生成草稿版本，记录申请确认的操作类型。
2. 将确认与任务、用户、草稿版本、有效期绑定，校验确认者是否有权执行该操作。
3. 实现同意、拒绝和过期路径；修改草稿内容后使旧确认失效。
4. 测试重复点击、其他用户确认、确认后修改、确认期间权限撤销和过期确认。
5. 保存操作审计信息，同时避免把敏感草稿全文散落到普通日志。

交付物： 确认接口与界面、授权记录、确认边界测试。

验收条件： 未确认、过期、内容已变化或操作者无权时不能提交；拒绝后任务停止；一次确认只能授权其绑定的具体操作。

第 15 周 处理重复执行和提交结果未知

本周目标： 避免重试与恢复制造重复工单。

1. 为提交生成稳定的幂等键，并在数据库中约束唯一性；同一键对应不同内容时拒绝处理。
2. 在模拟外部工单服务中分别实现支持幂等和不支持幂等两种接口，观察处理差异。
3. 注入“外部已创建但响应丢失”“本地记录前退出”“两个 worker 同时提交”等故障。
4. 为未知结果实现按业务标识查询、操作核对和人工处理入口；无法可靠确认时禁止盲目重试。
5. 对前面各周已有查询、草稿和审批场景运行回归。

交付物： 幂等提交、操作台账、结果核实任务与故障演练报告。

验收条件： 在约定支持的接口与故障模型中，重复请求只产生一次业务提交；无法保证的外部系统有明确核查路径；最终完成状态与真实工单一致。

第 16 周 建立端到端评测集与发布门槛

本周目标： 将“效果还可以”转成可复现的任务评测。

1. 汇总至少八十个练习任务，按查询、检索、无答案、审批、恢复和安全场景分类；人工复查预期结果。
2. 分开开发集与保留集；相似问题、同一文档改写和重复任务应避免跨集合造成泄漏。
3. 对写入任务查询测试数据库和模拟外部服务，检查对象、内容、数量和状态，不只检查最终回答。
4. 为任务成功、结构合法、引用支持、耗时和费用定义统计方式；为随机性明显的任务重复运行。
5. 在看保留集结果前写下练习版发布条件；任何越权执行或未授权写入都作为阻断问题处理。

交付物： 版本化任务集、任务判分器、评测报告和发布条件文件。

验收条件： 同一命令能够重建测试状态并生成报告；报告区分任务类型和失败原因；修复一个问题后能检测其他场景是否退化。

第 17 周 建立追踪与运维视图

本周目标： 从用户反馈追查到具体模型、工具和状态转换。

1. 将 request_id、task_id、模型调用 ID、工具调用 ID 关联，记录开始结束时间和错误分类。
2. 记录模型、提示词、检索配置与工具版本；对输入输出按敏感等级做脱敏、采样或受限保存。
3. 统计成功率、人工接管率、P50/P95 耗时、工具错误率和每个成功任务的成本。
4. 建立任务详情视图，展示证据来源、工具结果摘要、审批状态和停止原因。
5. 为模型不可用、工具错误增长和任务长时间无进展配置告警，并用模拟故障触发一次。

交付物： 结构化事件、运行看板、任务追踪示例与告警说明。

验收条件： 给出一个失败任务 ID，能够找到失败步骤和相关配置；告警能触发和恢复；没有敏感内容进入无权限的查看入口。

第 18 周 做一次系统化安全测试

本周目标： 验证恶意输入无法突破工具与数据边界。

1. 建立至少二十个攻击样例，覆盖制度正文夹带指令、恶意附件、伪造管理员、越权查询和敏感信息索取。
2. 在工具执行层再次检查对象权限；限制可用工具、可访问地址和文件范围。
3. 若实现任意 URL 抓取，测试内网地址、重定向和 DNS 变化等边界；若不需要抓取，保持工具不提供该能力。
4. 检查错误信息、日志、引用、缓存与追踪是否泄露其他租户内容或秘密。
5. 将每个成功突破边界的案例修复并加入回归，写出仍未覆盖的能力范围。

交付物： 威胁模型、攻击集、修复记录与安全回归报告。

验收条件： 已知攻击无法在当前测试范围内造成越权读取或写入；控制发生在执行层；尚未完成隔离的高风险能力保持关闭。

第 19 周 优化成本与长尾延迟

本周目标： 在明确质量约束下减少完成任务的资源消耗。

1. 按模型、检索、重排、工具和等待确认拆解耗时与费用；人工等待与系统处理耗时分开统计。
2. 选择一个主要瓶颈，尝试上下文裁剪、缓存、减少重复查询或任务模型路由中的一项。
3. 为缓存键包含权限范围、资料版本及必要配置；测试权限变化和文档更新后的失效行为。
4. 在同一任务集、相近并发和预算下比较优化前后结果，记录退化与改善。
5. 给单个任务设置费用上限并模拟耗尽；检查任务仍有清楚的结束说明。

交付物： 资源分解报告、一项优化实验、成本预算与回归结果。

验收条件： 质量与安全门槛没有因优化失效；缓存不会跨越权限边界；对无收益的优化给出撤回决定，不能只看单次 token 价格。

第 20 周 完成可重复部署与自动检查

本周目标： 让服务可以从干净环境稳定安装和运行。

1. 固定依赖，构建容器；区分开发、测试与运行配置；使用独立测试数据与秘密。
2. 配置数据库迁移、健康与就绪检查，说明服务启动依赖和失败条件。
3. 建立 CI，运行代码检查、确定性测试、模拟工具集成和一组规模受控的模型评测。
4. 付费模型评测设置预算与人工触发条件；常规离线测试不得误连真实写入接口。
5. 在隔离环境从空数据库部署一次，检查迁移失败和配置错误时的日志。

交付物： 部署文件、CI 配置、迁移说明、环境隔离与启动文档。

验收条件： 按说明从零部署成功；失败检查阻止继续发布；测试不会访问生产秘密或执行真实业务写入。

第 21 周 控制并发与处理服务压力

本周目标： 让排队、限流和取消具有可解释的行为。

1. 明确 HTTP 接入、任务执行与持久化的职责；需要跨进程任务时接入持久化队列与 worker。
2. 设置用户、租户和外部模型并发限制；队列满时明确拒绝或提示等待，避免无限堆积。
3. 测试任务领取、worker 退出、重复投递和取消；执行前后检查取消与租约状态。
4. 使用模拟模型完成逐级压测，再用受控的小流量验证真实依赖；记录吞吐、错误、队列长度和 P95。
5. 找到当前资源下开始明显退化的区间，据此设定运行上限与过载策略。

交付物： worker 与限流配置、压测脚本、容量报告、取消与重投递测试。

验收条件： 过载时内存与队列受到限制；取消任务不会继续启动新的提交；重复投递不会绕过第 15 周的幂等控制。

第 22 周 进行灰度与回退演练

本周目标： 让新版本可以有限试用，也可以及时停止。

1. 将模型、提示词、工具与检索配置组合成可识别版本，保存各次发布清单。
2. 设计按测试账号或稳定任务分组的灰度方式，保留旧配置与必要的状态兼容处理。
3. 注入新提示词退化、模型不可用和工具超时，验证告警与停用写入工具的开关。
4. 演练切回旧版本、暂停新任务和转为草稿模式；核对执行中的任务应继续、迁移还是终止。
5. 测试备份恢复，并写出数据库变更不能直接回退时的处理步骤。

交付物： 发布清单、灰度规则、回退手册和一次演练记录。

验收条件： 能停止扩大故障；已有任务状态不会被新旧版本错误解释；恢复结果经过数据核对，不能只以进程重新启动为成功标准。

第 23 周 优先修复主要失败类型

本周目标： 用完整实验完成一次有依据的质量改进。

1. 汇总前几周失败记录，按发生频率、业务损害和修复成本排序，选出最值得处理的一类。
2. 提出具体假设，例如“章节标题丢失导致相似条款误检索”；设计只改变主要变量的实验。
3. 在开发集迭代，冻结方案后评估保留集；展示有效、无效和退化样本。
4. 复查安全、恢复、延迟与费用，确认收益没有转移成其他代价。
5. 写出是否采用的决定与尚未解决的部分；没有明显改善时保留原版本。

交付物： 问题排序、实验设计、版本对比报告和上线或撤回决定。

验收条件： 他人能够复现实验；结论不只基于挑选的成功案例；问题原因、改动和指标变化之间有可检查的联系。

第 24 周 完成项目交付与能力复盘

本周目标： 把项目整理成别人能够运行、理解和审核的作品。

1. 从新环境重新部署，运行查询、解释制度、生成草稿、确认提交和中断恢复五条演示流程。
2. 整理架构、接口、数据结构、权限规则、评测集、费用报告与发布手册，移除失效说明。
3. 录制一次正常流程和一次故障恢复演示；公开材料只使用虚构数据。
4. 选取三个失败案例，分别说明现象、定位、取舍、修复与验证证据。
5. 按第 1、4、7、11、15、19、22 周里程碑复核能力，列出不能独立完成的部分和补练计划。

交付物： 可复现仓库、完整演示、项目说明和个人能力差距清单。

验收条件： 另一位开发者能够按说明运行；核心行为有自动验证和人工检查依据；已知局限写清楚。不能独立解释的模块，要回到对应周补做。

阶段未通过时如何补练

未通过的位置	优先补做的任务	再次验收的方法
第 2 周接口与权限	去掉模型，单独画数据归属和状态转换；修复 API 与事务测试	用两个租户重跑相同接口，检查响应与数据库
第 4 周输出与分类	拆开结构合法性和语义正确性；逐条标注错误，缩小分类范围	固定提示词和样本，输出两种指标及失败清单
第 7 周工具与运行器	使用模拟模型回放工具请求，检查预算、错误和终止状态	无真实模型调用也能稳定复现所有协议分支
第 11 周知识库	暂停生成回答，先检查正确证据在哪里丢失	用标注集验证候选证据、过滤和版本选择
第 15 周恢复与提交	用模拟外部服务逐个注入提交前后故障，补全操作台账	查询真实测试记录数量与任务最终状态
第 19 周评测与优化	固定数据、配置和运行条件，撤回同时改动的多个变量	比较同一任务集，明确收益与退化
第 22 周发布与回退	在隔离环境演练旧状态恢复、开关停用和数据恢复	按手册由另一人操作并核对数据

十一 第 25 至 52 周高级工程实践计划

后半程分为七个四周周期。每个周期都要经历问题定义、实现、故障或效果实验、交付评审；已有项目基础继续复用。高级能力需要真实约束与持续反馈，这二十八周用于组织实践，职级仍取决于承担的责任与实际成果。

第 25 至 28 周 长任务可靠性与容量设计

周次	必须完成的任务	当周交付
第 25 周	选取容易中断的一类长任务；定义成功、超时、恢复与人工接管标准；按模型、工具、存储与队列画故障清单；记录现有容量基线	服务目标、故障清单和基线报告
第 26 周	完善 worker 租约、重复投递处理、重试预算和失败队列；为过期租约与旧 worker 继续提交设计执行保护；检查写入仍遵守幂等约束	任务领取与恢复实现、并发提交测试
第 27 周	注入进程退出、数据库短暂不可用、模型限流和消息重复；逐级增加负载；统计任务丢失、重复执行尝试和恢复时间	故障与压力实验报告
第 28 周	处理最大的可靠性瓶颈；比较恢复和容量指标；计算资源成本；补齐值守手册与积压任务处理步骤	可靠性改进、容量边界和运行手册

周期验收： 任务账目可以核对；支持的故障条件下没有静默丢失或重复业务写入；超出设计范围时有明确降级和人工核查路径。未通过时先修复任务执行层，不增加协作角色。

第 29 至 32 周 验证多 Agent 是否适合任务

周次	必须完成的任务	当周交付
第 29 周	选择可以独立拆分的任务，如多份制度差异分析；建立单 Agent 与固定并行工作流基线；定义总时间、调用次数和费用预算	可比较任务集、基线与预算
第 30 周	实现协调、分析、汇总角色；规定输入输出与证据格式；共享资料按权限访问；限制角色数量、委派深度与终止条件	最小协作实现、角色契约
第 31 周	测试子任务超时、相互矛盾、重复证据和一个角色失败；规定汇总器如何保留分歧与不确定性；完成等预算对照实验	协作失败测试、质量成本对照
第 32 周	决定采用哪些协作环节；没有收益的角色删除；总结适用任务、收益来源与不适用情况；将有效方案接入回归	架构决策、保留方案和评审材料

周期验收： 结论来自同一任务集和相近资源预算；无法完成的子任务会显式暴露；汇总内容可追溯证据。保留单 Agent 也可以是合格结果，前提是有比较依据。

第 33 至 36 周 MCP 与外部工具集成

周次	必须完成的任务	当周交付
第 33 周	阅读所采用版本的 MCP 架构、工具与授权规范；选择两项已有能力；列出身份、传输、能力发现和数据边界；固定 SDK 版本	协议接入设计与契约
第 34 周	实现包含查询工单与检索制度的 MCP 服务；接入一个兼容客户端；保留现有业务权限校验和错误分类	可运行服务、客户端演示
第 35 周	验证无权限、身份过期、工具列表变化、网络中断和参数不兼容；若提供远程服务，按适用规范实现并测试认证授权	兼容性与安全测试报告
第 36 周	给第二个兼容客户端复用工具；比较协议接入与直接 API 的维护成本；整理配置、故障排查和升级步骤	复用演示、接入手册与升级方案

周期验收： 客户端接入不会改变业务授权；工具行为可以独立测试；协议错误与业务错误能够区分。只有本地服务验证时，交付范围应明确限定为本地场景。

第 37 至 40 周 模型选择与数据适配实验

周次	必须完成的任务	当周交付
第 37 周	抽样分析主要模型失败；区分资料不足、工具错误、需求模糊和模型能力不足；检查数据授权、隐私与标注一致性	失败归因与数据质量报告
第 38 周	比较至少两个可用模型或配置；使用冻结任务集和相同工具；统计质量、费用、延迟、拒绝与格式错误	模型选型实验与路由候选规则
第 39 周	根据证据选择一个方向：改进提示词、修复数据供给、任务路由，或在有数据与预算时做微调小实验；若训练，划分去重后的训练、验证和保留集	适配实现、数据划分与实验记录
第 40 周	冻结配置后评估保留集与分布变化样本；检查安全回归、维护成本和回退方式；决定是否采用	适配效果报告和采用决定

周期验收： 能说明变化解决了哪类问题；没有把训练样本混入最终评估；只有具备有效数据与成本收益时才采用微调。选择不训练，需要写出更合适方案的证据。

第 41 至 44 周 抽取可复用平台能力

周次	必须完成的任务	当周交付
第 41 周	增加第二个小场景，如 IT 故障知识问答；比较两套场景中模型接入、工具、权限、预算、评测和追踪的重复部分	重复问题清单与公共接口草案
第 42 周	只抽取已经重复出现的能力；实现配置版本、模型适配与工具注册等必要模块；明确业务逻辑仍由场景负责	最小公共运行模块与边界说明
第 43 周	将两个场景接入；测试租户隔离、配置错误、公共模块升级与一个场景故障对另一个的影响	双场景集成与隔离报告
第 44 周	请另一位开发者按说明添加第三个最小工具或场景；记录接入时间与困惑；修复接口和文档，不为假想需求扩大平台	接入反馈、迁移说明和公共模块版本

周期验收： 至少两个真实实现可以复用；新增场景不需要复制运行器或绕过权限；公共能力的维护成本与收益有记录。没有协作者时，可以在全新目录按文档接入，并说明尚未完成外部使用验证。

第 45 至 48 周 受控业务试点与价值评估

周次	必须完成的任务	当周交付
第 45 周	选择边界明确的试点任务；取得参与者与数据使用授权；记录人工处理时间、错误与返工成本；定义停止条件	试点计划、人工基线和授权范围
第 46 周	先以影子运行或只生成草稿方式接入，输出不直接改变业务；与人工结果比较；建立反馈与问题追踪入口	对照结果与反馈记录
第 47 周	仅在通过安全与质量门槛后扩大到已批准范围；记录人工接管、修正时间和异常；达到停止条件立即暂停	小范围运行报告与异常处理记录
第 48 周	计算总处理时间、模型工具费用、人工复核和返工成本；与人工基线比较；决定扩大、修改还是停止	业务价值报告与下一步决定

周期验收： 成果以实际完成任务和总成本为依据；自动化比例与人工复核时间一起报告；样本少或没有真实试点时，将结论限定为模拟或小规模验证。

第 49 至 52 周 独立负责一次完整技术迭代

周次	必须完成的任务	当周交付
第 49 周	从试点中选择一个高价值问题；写技术方案、备选方案、风险、工作量和验证计划；组织评审或请同行审阅	需求与技术方案、评审意见
第 50 周	按方案实现并拆分任务；审核关键代码和数据变更；补齐评测与兼容处理；记录与原方案不同的取舍	可审核实现和变更记录
第 51 周	运行发布前评测、故障和回退演练；按批准范围发布或在模拟环境演练；跟踪指标与反馈	发布记录、运行数据与问题清单
第 52 周	复盘结果与成本；整理架构决策、典型故障和团队约定；规划未来三个月；向其他开发者讲解并回答质疑	技术复盘、维护交接和后续计划

周期验收： 能独立说明问题价值、架构选择、验证证据、发布结果与遗留风险；另一位开发者能够接手维护。学习周期结束后，继续积累跨版本运行、复杂故障与团队协作经验。

十二 用一个完整项目展示成长成果

完成模型调用、工具与审批阶段后，可以接着做Agent 工程师实战教程，按正文中的完整 Python 实现练习工具执行、权限校验、草稿确认和幂等提交。

作品集可以围绕同一个知识库与工单助手持续演进。保留从普通 API、单个 Agent 到可恢复工作流的关键版本，说明每次复杂度增加解决了什么问题。

项目至少应提供以下材料：

1. 可复现的运行说明。 包括环境配置、脱敏示例数据、依赖和启动方式。
2. 明确的任务与边界。 说明可以处理哪些问题、可以执行哪些操作、哪些情形需要人工接管。
3. 架构与工具契约。 展示状态如何流转，以及身份、数据和外部操作如何被约束。
4. 评测与成本报告。 写明样本范围、版本、成功标准和运行条件，避免只展示一次成功演示。
5. 失败案例与改进记录。 至少包含检索错误、提示注入、工具超时和重复提交问题的分析。

面试时，可以选择一个真实失败讲清楚：用户要完成什么，系统在哪一步偏离预期，你如何定位，为什么选择这个修复，以及哪些测试说明问题得到改善。

当你能够独立完成这样的项目，已经具备了讨论 Agent 工程岗位的具体材料。继续向高级发展，需要在真实使用中积累对任务价值、运行风险和架构成本的判断，并把这些经验转化为团队可以复用的方法。