TL;DR：我完成了 Future AWS Agent Engineer 纳米学位，三个计分项目都是为一家虚构网店搭建客服系统：第一个是聊天机器人，第二个是单个 Agent，第三个是五个 Agent 协同工作。项目一个比一个难，遇到的问题却一个比一个少，因为每次踩过的坑都变成了下一次构建里的检查项。下面说说这三个项目怎么对比、中间发生了什么变化，以及为什么最后一个虽然拿了 120 分满分，却还是被打回来补交材料才通过。
这个纳米学位的第一个项目，我是在八月的截止日当天交的。那是一个只有一条系统提示词的聊天机器人，评分标准还是照着 AWS 已经不再向新客户提供的产品写的。项目通过了。可那天大部分时间我都在担心它不算数，因为代码不是我敲的。
第二个项目一个月后交，一次会话就做完了。它是一个 Agent，能查订单、处理退款、搜索商品目录，代码里还加了归属校验，不会把别人的订单展示给你。也是它让我第一次见识到一个光存在就按小时计费的数据库。
第三个项目是十月的一个周日晚上交的。里面有五个 Agent、两个模型、三个同时检索的知识库，每次模型调用都过一道安全过滤。从 Udacity 原封不动的起始文件到测试套件满分，用了不到四小时。
项目一个比一个难，麻烦却一个比一个少。这出乎我的意料，我想弄明白原因，所以这篇文章把三个项目放在一起对比。
一个交汇点，一个帮手，一个议事会
AWS AI & ML Scholars 项目由 Udacity 承办。我参加的是 Agent Developer 方向，对应的纳米学位 Future AWS Agent Engineer 有三个计分项目。三个项目都是为一家虚构网店搭建客服系统。问题本身没变，所以我能直接对比这三次构建，而且一次比一次工具多。
三个项目都跑在 Amazon Bedrock AgentCore 上。这是 AWS 的托管服务，把 Agent 里本来要自己搭的部分都包了：调用模型、记住对话、运行工具，以及托管整个应用。
第一个项目是 Nova Trivium，我在 Future AWS Agent Engineer? I Didn't Write the Code. Does It Count? 里写过它。trivium 指三条路交汇之处。一条系统提示词把每条消息导向三条路径之一：提交 bug 报告、根据粘贴的 FAQ 作答，或转接人工。
第二个项目是 Nova Adiutrix，记录在 Nova Adiutrix: my second agent built my first project's to-do list 一文中。adiutrix 意为帮手。这个 Agent 负责跟踪订单、处理退款、检索存放在知识库（一种托管存储，Agent 可按语义而非精确字词搜索）中的商品目录，并且拒绝展示他人的订单。
第三个项目是 Nova Concilium。concilium 意为议事会。五个 Agent 各司其职，由一名编排者决定谁来发言。
Nova Concilium — NovaMart 多 Agent 客户支持系统
状态： nd905 课程四结课项目的提交版 README——已完整收录 120/120 测试运行结果及两张 X-Ray 截图。本文件为提交版 README；Udacity 原始起始 README 保留在 git 基线提交
7ea6508中（未改动的起始版本）。账户 ID 与运行时 ARN 有意省略（为公开分享做了脱敏处理）。
Nova Concilium（拉丁语，意为"议事会"）是为虚构电商公司 NovaMart 打造的五 Agent 客户支持系统，基于 Amazon Bedrock AgentCore 与 Strands Agents SDK 构建。编排 Agent 将每个请求路由给专职工作 Agent，通过跨三个知识库的并行多 Agent RAG 检索有据可依的政策答案，强制执行 Bedrock Guardrail，用 DynamoDB 配合乐观锁维护共享状态，并可通过 CloudWatch 与 X-Ray 实现端到端可观测。
这是什么
NovaMart 的支持团队负责处理订单状态、退货退款和政策咨询，方式是……
下面是三者的对比：
我会先看“我怎么知道它管用”这一行。项目越往后，测试越严格；测试越严格，我就越相信那一列里的其他内容。
每个项目都还清了上一个项目的清单
在 Nova Trivium 的 README 末尾，我写了一节叫“没做的，以及为什么”。里面列了三项我略过的东西：检索、护栏、结构化输出。
Nova Adiutrix 在我没计划的情况下做完了其中两项。重读旧 README 时，我做到一半才注意到。那篇帖子结尾是这么写的：“那份‘没做的，以及为什么’清单上的第三项是护栏。还是没做。项目三进展如何，我会告诉你们。”
到了 Nova Concilium，护栏成了评分要求。Amazon Bedrock Guardrails 是一个过滤器，检查进出模型的内容。我们的配置会拦截竞品话题、讨价还价和法律威胁，并对个人详细信息做脱敏。它起作用的第一个迹象，来自一个跟它无关的测试。一位客户的邮箱地址在测试记录里返回时变成了 {EMAIL}。
清单就此清空。这些项目的完成顺序不是我选的，是课程选的。
摩擦向外转移了
三次构建都出过问题。变的是问题的来源。
每一课都再次出现了
之前每一课的落点如下：
先建知识库，再写规格
要说功劳最大的改动，得算在写代码之前的那一步。
之前的项目，我直接给 Kiro 一份构建规格。这次我先让 Anthropic 的 AI 模型 Claude 写了一份知识库：一个 markdown 文件，收录所有课程页面、评分标准、起始仓库，再加一张表，列出这些来源之间所有互相矛盾的地方。一共 13 处。然后，在写任何规格之前，Kiro 先读了起始文件，把这 13 处逐一核对。其中 11 处能对照文件解决。剩下两处没有文件可查：一组代码里还没定义的名称，以及截止日期。
先核对文件、再写规格，这个做法直接来自 Nova Trivium 项目——那次我围绕一个从未完整列出的起始仓库做规划。每个值还必须注明来自哪个文件，否则就标记为 UNVERIFIED。
分工还是三块，和之前一样。Kiro 写代码。Claude（Opus 5.5）写知识库，并对照起始文件审查 Kiro 规格的每个阶段。我负责指挥、做 Console 那边的工作、截图，以及拍板。
Claude 的审查在 Kiro 的需求里挑出了四个问题。文件夹还不是 git 仓库，所以两个检查点跑不起来。有一个测试被安排在它所依赖的部署之前。护栏测试需要示例提示词，但没有任何文件提供，Kiro 只能自己编。还有两个 Agent 只能在部署之后检查，Claude 建议改成能更早运行的检查。
我一开始卡得太死，后来放开了
最初的计划是让 Kiro 每完成一个任务就停下来等我批准。早期我跟 Claude 说，别再过度约束构建过程了。我欣赏细致，但我需要保持推进。
我们把停顿砍到四个，都是需要我出面或花钱的节点：在 Console 里创建知识库之前、首次部署之前、任何 git push 之前，以及拆除环境之前。其余环节 Kiro 一路跑完，边跑边贴输出。
从光秃秃的起始文件到满分，整个流程就是在这次改动之后跑完的，用了不到四小时。我觉得停顿少了，是它跑这么快的一大原因。
两个 Agent，一分钱
三个评分测试场景里有一个问的是：5 件商品，每件 $29.99，打九折，一共多少钱？
精确答案是 $134.955，所以必须四舍五入。最近一次运行中，编排器算出的结果是 $134.96，随后交给 Communication Agent 处理。后者先把折扣四舍五入到 $15.00，再算出 $134.95，最终回复写的是 $134.95。而同一次测试的早前运行中，最终回复写的是 $134.96。
初始代码里的舍入规则写在编排器的指令中。负责撰写客户所见回复的 Communication Agent 却提前做了舍入。从日志来看，编排器算出的数字从未进入 Agent 共享读取的记录，于是 Communication Agent 按自己的方式又算了一遍。
测试照样通过了。编写验收检查时，Claude 指出答案取决于舍入模式，建议同时接受 $134.95 和 $134.96，因为这项测试要考察的行为是护栏没有拦截数学问题。我同意了。接受任一答案符合评分标准，也正是因为如此，两个 Agent 之间一美分的分歧才一路通过了所有测试。直到我为了写这篇文章翻看日志，才有人注意到这件事。
这是我这个月第二次遇到一美分问题。在 Eight Minutes to Live. Was It Cursor, or Was It the Spec? 一文中，我用 Cursor 做的小费计算器把 1,437.50 的账单分成三份，每份 479.17，加起来却是 1,437.51。多出的那一美分之所以悬而未决，是因为我的规格说明从未规定它该归谁。
那篇文章的评论比文章本身更有价值。flatin.pt 建议金额一律以整美分为单位，余数按固定顺序一分一分地分配，这样各份之和永远对得上。Matt Busel 建议把规格说明当作假设而非契约，每次检查发现缺口就更新它。Vlad Zoff 建议把验收检查与构建分开，这样构建者就无法重新定义评判标准。
Vlad 的观点与这次的一美分问题最贴近。放宽检查、接受任一答案，就评分标准而言是合理的决定，但终究还是构建者在改动测试。两次一美分问题都源于同一个缺口：小费计算器里没有规则说明多出的一美分归谁，Nova Concilium 里没有规则说明以谁的数字为准。如果采纳 Matt 的建议，下一份规格说明会指定一个 Agent 作为所有计算的负责人，并让它在任何人给客户写回复之前先把结果存入共享记录。
满分，但证明不足
当晚我提交了 Nova Concilium。不到一小时，审核者就把它退了回来。
反馈很客气，说我的代码是模块化、文档齐全的 Agent 代码范本。接着却要求我完整部署方案，包括所有知识库和 AgentCore 部署，并附上每一项的截图。它要的东西早已部署好、跑在我的 AWS 账户里，评审却根本看不到。
书面交付物包括代码、知识库、填好的配置文件、测试成绩截图，以及一张 X-Ray 服务地图截图——这张图画出每个请求穿过各个 Agent 的路径。
这些我全都提交了。可没有任何页面要求提供控制台截图或测试运行输出。
这个缺口仍然得我自己发现。Kiro 最初写的要求里说，每个检查点的输出都要存进 evidence 文件夹。后来我们赶进度，结果只以文字形式写进了 README。Claude 在评审时没指出来，我也没核对那一行就批准了提交。既然是我批准的，漏掉就是我的责任。
这次疏漏还有第二层教训。评分标准写明知识库是"在 AWS 控制台中创建"的，系统"部署到了 AgentCore Runtime"。评审没法登录我的账户，所以对这两条来说，截图是唯一的证明。我的检查清单只问了每件事有没有做，它该问的是：我账户之外的人能不能看到这件事已经做了。
我补上控制台截图和测试运行输出，重新提交，通过了。10 月 27 日，证书到手。
课程访问权限到期前，我让 Claude 帮我把每节课都整理成笔记：四个 markdown 文件，每门课一个。我想把知识带走，用到以后的构建里，而不是等课堂关闭就丢掉。
这三个项目仍然无法告诉我什么
- 换到一个没有起始文件可供对照的项目，我的流程还站得住吗？
- 一套 120 分的测试，衡量的真是客户在意的东西吗？它可没抓到那枚一美分硬币。
- Nova Concilium 上的那些争执，有多少之所以轻松，只是因为前两个项目已经让我吃过苦头。 ## 这算数吗？
本系列第一篇文章问的是：我一行代码都没敲，指挥 Agent 算不算学习？
做完三个项目，我能说清楚自己学到了什么。我摸清了知识藏在哪、规则在哪里落地、怎么写出一个Agent没法靠嘴皮子绕过去的校验。到最后一个项目，我明白了一件事：满分和能过审的提交，是两码事。
难度一次比一次高，搭建却一次比一次轻松。下面这张经验表就是证据。七条经验，每一条都是某处出了故障才学到的，又都作为检查项写进了下一个项目。三个项目给我的本事就是这个：让下一次搭建出问题的地方更少。如果有谁也把同一件事做了三遍、看到了不一样的东西，我很想听听。
证书上说这算数。嗯……我也这么觉得。
新来的朋友，先交代几句背景。我在加州法院系统工作，负责一个县的法庭运营。2025年7月开始用AI做东西，之后一直公开记录学习过程。代码不是我写的。我负责指挥，Agent负责生成，我来验证和拍板。我在做Clew Suite，一套公民科技工具，目的是让复杂系统更容易被审视。我就是从这个视角写的。
2026年10月在AI辅助下完成。Kiro写了代码，Claude（Opus 5.5）写了知识库、审了规格说明，还帮忙起草了这篇文章。三个仓库都是公开的，引用我之前请先去看。
AI辅助，人工把关。由NLP驱动。
