ELEC5620 项目指南：One-Person AI Company（Tutorial 1 + Lab 1 + Project Description）
ELEC5620 项目指南：One-Person AI Company
来源：
Project Description.pdf+ELEC5620-TUT-01.pdf（39 页）+ELEC5620-Lab-Note-1.pdf项目占比：50%（Stage 1 = 30%，Stage 2 = 20%）Tutorial 1 的定位（slide 2）： ⭐ "The goal: leave with one real problem worth investigating—and a disciplined way to model it as a One-Person AI Company." （目标：带着一个值得研究的真实问题离开，以及一套有纪律的方法把它建模成一家 One-Person AI Company。）
Tutorial 1 的五个环节：Welcome & course → Architecture Review of Lecture → AI + learning case → Customer & business thinking → Company workshop。
一、项目背景与主题
随着大语言模型的快速发展，智能体（intelligent agents）已经具备规划、决策、工具使用和协作的能力。这使得一个人运营一家由多个专业化 agent 支撑的 AI 驱动虚拟公司成为可能。
项目主题：One-Person AI Company
学生需要设计并实现一个 LLM 驱动的多智能体系统（multi-agent system），其中：
- 不同 agent 承担不同的业务角色
- 协作完成任务
- 使用外部工具
- 根据结果调整自己的行为
通过问题定义 → 系统建模 → 实现 → 测试 → 评估的完整过程，把 model-based software engineering 技术应用到智能体系统上。
可选应用领域（七选一）
| # | 领域 | # | 领域 |
|---|---|---|---|
| 1 | Healthcare | 5 | Smart Personal Assistant |
| 2 | Finance | 6 | Smart Cities |
| 3 | Smart Home | 7 | Education |
| 4 | Retail and E-commerce |
二、Stage 1：需求文档、架构设计与系统建模（30 分）
2.1 报告部分（15 分）
提交一份正式报告，必须包含：
| # | 要求 | 对应的 UML/产出 |
|---|---|---|
| 1 | 需求的清晰分类：agreement（约定）、mandatory capabilities（强制能力）、optional features（可选特性） | 需求分类表 |
| 2 | User requirement diagram 和 Feature diagram | 需求图、特性图 |
| 3 | 主要特性的 use case 描述，包括用户与流程如何与系统交互的步骤 | Use case diagram + 步骤说明 |
| 4 | 系统结构与生命周期流程的描述：高层组件、互连与相互依赖 | Package diagram、Class diagram、collaborations、structured class |
| 5 | ⭐ 关键组件的行为描述，特别聚焦于 LLM 在 agent 系统中的角色；支撑组件简要描述即可 | Activity diagram、State machine、Sequence diagram |
| 6 | 关键组件之间的关系，用以说明对未来开发工作的支持 | 关系图 |
| 7 | ⭐ 设计过程中所做的假设（assumptions） | 文字说明 |
⚠️ 第 5 条是本项目的核心差异点——必须把 LLM 在 agent 系统中扮演什么角色讲清楚，而不是把 LLM 当成一个黑盒 API。
2.2 Presentation 与 Interview（15 分）
演示 slides 必须覆盖：
| # | 内容 |
|---|---|
| 1 | 提出的需求及其分类（以便最终确定需求） |
| 2 | ⭐ 提出的设计，以及设计选择的理由（rationale）—— 包括被放弃的选项（discarded choices） |
| 3 | 所有模型的总览（Overview of the models / all UMLs） |
| 4 | ⭐ 变更评估与验收判定的依据（The basis for change assessment and acceptance determination） |
⭐ 第 2 条是最容易丢分的地方：不能只说"我们选了 X"，必须说明为什么选 X，以及为什么放弃了 Y 和 Z。这正好呼应 Week 1 讲的 architecture trade-offs。
2.3 其他
- ⭐ 必须清楚写明每位组员的贡献（The contribution of each group member should be specified clearly）
- Tutorial 版本提到 Stage 1 还包含 video presentation（slides required）
三、Stage 2：原型实现与演示（20 分）
基于 Stage 1 的架构设计实现一个 proof-of-concept 原型，向 stakeholders（tutors）演示。必须实践 Agile 软件开发模型（课上会讲）。
四条要求：
| # | 要求 | Tutorial 给出的评分细节 |
|---|---|---|
| 1 | 基于 Stage 1 的需求和设计开发，实现大部分模型 | ⭐ 核心特性是强制的；特性的数量和质量都会被考量 |
| 2 | ⭐ 演示 LLM 如何增强 agent 的感知、决策与交互能力 | 使用 LLM 的证据；合理的用法与设计 |
| 3 | 反映使用 Agile 开发模型的经历 | ⭐ Jira 的时间线作为证据 + 支撑文档 |
| 4 | 在软件中使用先进技术 | 包含的技术数量，以及是否开发完善 |
时间安排：
- Demonstration 在最后一周（Week 13）进行
- ⭐ 项目源代码必须在最后一周的周一之前上传到 Canvas
四、Tutorial 1 核心概念（一）：AI Agent
4.1 ⭐ LLM 不会自动成为 Agent（最重要的一张对比表）
| LLM | AGENT |
|---|---|
| 生成和转换语言（Generates and transforms language） | ⭐ 跨多个步骤追求一个目标（Pursues a goal across multiple steps） |
| 响应当前的 prompt（Responds to the current prompt） | ⭐ 使用工具并观察结果（Uses tools and observes results） |
| ⭐ 可能不知道自己的回答是否改变了世界（May not know whether an answer changed the world） | ⭐ 在约束内选择下一步行动（Chooses the next action within constraints） |
⭐ Tutorial 给出的设计箴言： "The design question is not 'Which model?' first. It is 'What loop should the system responsibly complete?'" （首要的设计问题不是"用哪个模型"，而是"这个系统应当负责任地完成什么样的循环"。）
4.2 Agent 的定义与构成
An agent is an autonomous entity capable of: perceiving its environment, making decisions, taking actions.
三个模块：perception（感知）、decision-making（决策）、action（行动）。
LLM 何时成为 agent 的一部分：
⭐ 当它运行在一个 goal-directed loop（目标导向的循环）中时：观察环境 → 选择行动 → 使用工具 → 评估结果。
Agent 如何扩展 LLM：
gathering evidence（收集证据）、maintaining state（维护状态）、using tools（使用工具）、completing multi-step tasks（完成多步任务）
4.3 工具（Tools）
如果给 agent 配上工具，它会变得更强大——更高效、更准确。
能做什么：检索和处理数据、与外部服务交互、自动化任务、进行复杂分析。
工具举例：
| 类别 | 例子 |
|---|---|
| 数据查询与处理 | SQL、Apache Hadoop |
| 外部信息与服务 | Google Maps API |
| 自然语言处理 | NLTK、spaCy |
| 机器学习/深度学习框架 | TensorFlow、PyTorch、sklearn |
4.4 ⭐ Multi-Agent System（MAS）
A Multi-Agent System (MAS) is composed of multiple agents that can interact, collaborate, and even compete with each other to accomplish complex tasks. （多个 agent 相互交互、协作、甚至竞争以完成复杂任务。）
应用范围：robotic control、logistics management、financial trading、intelligent transportation、game design。
| 层面 | 关注点 |
|---|---|
| 对每个 agent | 不同的角色与职责；实时决策；处在动态变化的环境中 |
| 对系统设计 | ⭐ 仔细规划每个 agent 的行为；⭐ agent 之间的交互与协调机制 |
经典案例：AI Agent Town: Generative Agents（Stanford）
📌 这两条"系统设计"要点，就是你 Stage 1 报告里 sequence diagram 和 collaboration 要回答的问题。
五、Tutorial 1 核心概念（二）：三个案例讨论
这三个案例都不是闲聊——它们是在训练你做架构权衡时的判断力，而且很可能出现在 interview 提问里。
5.1 案例一：AI 与学习
讨论题：⭐ "If AI helps you finish faster, what might you stop learning?"
Tutorial 引用的研究数据：
| 组别 | 完成速度 | 即时测验得分 |
|---|---|---|
| AI-assisted | 快约 2 分钟（差异不具统计显著性） | 50% |
| Hand coding | — | 67% |
⭐ 17 个百分点的差距。
⭐ 核心结论："Completion and comprehension are different outcomes."（完成和理解是两种不同的结果） "a completed task can conceal a weaker mental model of the system."（一个已完成的任务，可能掩盖了对系统更弱的心智模型）
两种使用 AI 的方式：
| DELEGATE TO FINISH（委托以完成） | USE AI TO UNDERSTAND（用 AI 来理解） |
|---|---|
| 生成完整解决方案 | 问概念性问题 |
| 让 AI 调试每一个失败 | 要求"解释 + 代码" |
| 复制、运行、继续下一个 | 检验自己的理解 |
| ⭐ 更少的独立推理 | ⭐ 独立解决一部分错误 |
⚠️ Slide 自带的严谨性说明：该研究发现的是交互模式与结果之间的关联，并未确立每种模式的因果效应。
5.2 案例二：免费的 AI 助手真的免费吗？
服务可能仍然让你付出：
- 个人和项目数据
- 核查不可靠输出所花的时间
- ⭐ 独立学习能力的丧失
- 对单一平台的依赖
- 对数据与输出如何被使用的控制权有限
⭐ 讨论题："If the monetary price is zero, who pays, what do they pay with, and who captures the value?" （如果金钱价格是零，那么谁在付费、用什么付费、又是谁攫取了价值？）
5.3 案例三：缺乏人类判断的 AI 治疗师
背景：AI 心理健康聊天机器人越来越被使用，因为它们便宜、随时可用、比人类治疗师更容易获得。
一个 AI 聊天机器人可能会：
- 迎合或强化用户已有的信念（mirror or reinforce a user's beliefs）
- 在缺乏充分临床证据的情况下给出自信的建议
- ⭐ 无法识别正在发展中的危机（fail to recognise a developing crisis）
- ⭐ 通过持续的肯定鼓励情感依赖
- ⭐ 对其建议的后果不承担责任
⭐ 社会风险的核心表述：
If vulnerable users replace qualified human support with systems that cannot reliably challenge, escalate, or take responsibility, greater access may also produce greater harm.
（如果脆弱的用户用无法可靠地质疑、升级或承担责任的系统，去替代有资质的人类支持，那么更高的可及性也可能带来更大的伤害。）
三种设计定位，选哪一种？
| 选项 | 定位 |
|---|---|
| 1 | 独立的治疗师（an independent therapist） |
| 2 | 人类治疗之间的支持工具（a support tool used between human therapy sessions） |
| 3 | 筛查与转介系统，把用户连接到有资质的专业人士（a screening and referral system） |
⭐ 真正的考题："What architecture and human safeguards would your choice require?" （你的选择需要什么样的架构和人类保障机制？）
📌 这直接对应 Week 1 讲的 "Build guardrails" 和 human oversight——如果你的项目选 Healthcare 方向，这一题基本就是你的设计答辩题。
六、⭐ 从客户需求到系统设计：StrideWise AI 完整示例
这是 Tutorial 1 最有价值的部分——它给出了从"一句话商业想法"到"工程需求"的完整链条。
6.1 第一步：拆解表层请求
Deconstructing the Shoe Shopper
| 层次 | 内容 |
|---|---|
| Surface Request（表层请求） | "I want to buy a pair of running shoes." |
| ⭐ Underlying Need（底层需求） | Financial confidence（价格/价值上的信心）、Fit accuracy（合脚，避免疼痛/受伤）、Trust（减少选择过载） |
| Business Goal（业务目标） | 更高的转化率、更低的退货率、更高的客户信任 |
⭐ Key Takeaway：
"An AI recommendation engine must solve the underlying hesitation, not just push sales." （AI 推荐引擎必须解决底层的犹豫，而不只是推销。）
6.2 第二步：写 Company Brief
StrideWise AI 的正式版本：
Company Name: StrideWise AI Purpose: A One-Person AI Company for Personalised Running-Shoe Decisions Company Brief: For runners who struggle to choose suitable shoes, StrideWise AI coordinates fit-analysis, product-research, inventory, and customer-support agents to recommend available shoes that match the customer's feet, running style, and budget. ⭐ The human founder reviews health-related advice, uncertain recommendations, and exceptional cases.
6.3 ⭐ 一句话 Company Brief 模板（直接拿去用）
For [target user] in [situation], [problem] occurs because [cause]. Our one-person AI company coordinates [agent roles] to [outcome], while the human founder approves [high-impact decision].
五项检查清单：
| ✓ | 项目 |
|---|---|
| □ | specific user（具体的用户，不是"所有人"） |
| □ | real evidence（真实的证据，不是想当然） |
| □ | measurable value（可测量的价值） |
| □ | multi-agent roles（多个 agent 角色） |
| □ | ⭐ human accountability（人类问责——创始人批准什么） |
展开版模板（slide 37 的句式）：
(公司名) is a one-person AI company designed to (目标) in (场景) by (手段) based on each customer's (输入维度). The company coordinates specialised AI agents and technologies—including (技术栈)—to (具体动作序列).
6.4 ⭐⭐ 第三步：需求 → 系统设计的映射表（最重要）
StrideWise AI: From Customer Need to System Design
| Agent Element | StrideWise AI 示例 | Engineering Requirement（工程需求） |
|---|---|---|
| Environment（环境） | 客户、脚部、产品和库存数据 | 安全的数据模型与 API 集成 |
| Perception（感知） | 捕捉偏好、分析足部扫描 | 多模态处理与偏好抽取 |
| Decision-Making（决策） | 按合脚度、舒适度、价格、可获得性对鞋进行排序 | 推荐逻辑与约束检查 |
| Action & Tools（行动与工具） | 解释推荐理由、预留鞋子 | 库存 API、确认与响应生成 |
| Feedback（反馈） | 记录试穿、满意度、退货、拒绝 | 可追溯的反馈与模型精化 |
| ⭐ Human Oversight（人类监督） | 审查健康相关问题和不确定的案例 | ⭐ 置信度阈值、升级机制与审批规则 |
📌 这张表就是你 Stage 1 报告的骨架。 左列是通用的 agent 六要素，中列是你的业务场景，右列是要写进架构设计的工程需求。 照着这个结构填自己的项目，Stage 1 的"关键组件行为描述"就有了。
七、Lab 1（Week 2）：组队与选题
7.1 Part One：自我介绍与组队
破冰问题：
- 是什么驱动你参与这个项目？
- 这学期你最期待什么？
- 你以前接触过 agentic AI 或 LLM 吗？
- 你能给团队带来什么技能或优势？
- 你有兴趣探索或深入了解哪些领域？
组队规则：
- 3–5 人，⭐ 争取技能组合多样化，以便应对项目的不同方面
- ⭐ 在 Canvas 上加入对应自己 lab 时间的组
- ⭐ 组名格式必须是「lab 时间 + 组号」，例如
Mon 10-12 Group 1
7.2 Part Two：选题
- 讨论、设计、开发一个利用 Agentic AI 协作解决复杂问题或任务的软件项目
- AI agent 的定义（Lab Note 版）：能感知环境、做决策、基于预定义规则或习得经验采取行动的自主软件实体，并由 LLM 提供增强能力
- ⭐ 选一个所有成员都真正感兴趣的题目
- 参考现有的 LLM 应用作为灵感
- ⭐ 争取解决澳大利亚本土的相关挑战，以吸引业界关注
7.3 Part Three：项目考量五点
| # | 考量 |
|---|---|
| 1 | ⭐ 准备 1–2 个候选题目——多个选项能带来更丰富的讨论和灵活性 |
| 2 | ⭐ 清晰定义你的软件要解决的真实世界问题——理解这个问题会指导你的设计与实现 |
| 3 | 确定你的 agent 需要什么类型的 LLM；探索可用资源，⭐ 确保 LLM 集成显著增强了 agent 的能力 |
| 4 | ⭐ 确保项目与 Agentic AI 有强关联——目标是 "One-Person AI Company" |
| 5 | 考虑软件对目标行业的潜在影响：如何精简流程、提升效率、提供创新方案 |
7.4 Part Four：项目文档（Lab 1 的产出）
需要准备一份文档，包括但不限于：
| # | 内容 |
|---|---|
| 1 | 项目场景（The project scenario） |
| 2 | 关键功能概述（An outline of the key functionalities） |
| 3 | 目标用户或受益者的识别 |
| 4 | ⭐ 每位组员角色与职责的明确说明 |
| 5 | ⭐ 团队协作、沟通与冲突解决的准则（guidelines for team collaboration, communication, and conflict resolution） |
| 6 | 项目目标、范围与意义的全面概述，⭐ 强调 Agentic AI 的角色 |
💡 第 5 条容易被忽略但明确写在要求里——冲突解决机制要写进文档，别跳过。
八、工具清单
| 类别 | 工具 |
|---|---|
| 建模 | StarUML、draw.io、Papyrus UML |
| 项目管理 | ⭐ Jira（Stage 2 需要 Jira 时间线作为 Agile 实践的证据） |
| 版本控制 | Git |
| 开发环境 | VS Code、Jupyter Notebook、PyCharm、Spring Tools Suite |
| 云服务 | Amazon Web Services |
| Agent 框架 | ⭐ LangChain、LangGraph、Llama-Index |
| Vibe coding | Codex、Claude Code、Cline、Continue |
⚠️ API key 提醒：课程提供的 key 基于讲师个人账号，目前每组仅 $10，只能用于开源 coding agent（不含 Codex / Claude Code）。不强制使用 AI，传统开发方式同样可以。
九、时间线与检查清单
| 时间 | 事项 |
|---|---|
| Week 2（Lab 1） | ⭐ 组队（3–5 人，同 lab）、在 Canvas
注册（Mon 10-12 Group 1 格式）、准备 1–2
个候选题目 |
| Week 5 | ⭐ Stage 1 checkpoint |
| Week 8 | ⭐ Stage 1 截止：报告提交 + presentation 和 in-class interview（必须到场） |
| Week 9 | Midterm 线上 quiz（开卷，在家做） |
| Week 13 | ⭐ Stage 2：周一前上传源代码 + in-class demonstration（必须到场） |
Stage 1 报告自检清单：
Stage 2 自检清单：
十、把两周内容串起来
Week 1 讲座和 Tutorial 1 其实在说同一件事，只是一个抽象一个具体：
| Week 1 讲座（抽象） | Tutorial 1（具体） |
|---|---|
| Design from customer value backward | Deconstructing the Shoe Shopper：表层请求 → 底层需求 |
| Narrow promise：一个客户、一件痛苦的事、一个可测量结果 | Company brief 模板的五项检查清单 |
| Map the work：分离 judgment / repeatable tasks / risky exceptions | Human Oversight 行：创始人审查健康问题和不确定案例 |
| Build guardrails：数据访问、质量检查、审批、降级 | 置信度阈值、升级机制、审批规则 |
| Create memory：存决策、样例、指标、教训 | Feedback 行：可追溯的反馈与模型精化 |
| DESIGN TEST：能否在创始人不介入每一步的情况下反复交付价值 | AI 治疗师案例：系统能否可靠地质疑、升级、担责 |
| 架构控制快速生成的爆炸半径 | "What loop should the system responsibly complete?" |
⭐ 最后记住老师那句把 Stage 1 和 Stage 2 连起来的话： "如果你的设计报告把每一部分都写清楚了，Stage 2 可能会非常简单——你只要把每一部分丢进编码 agent，软件就会被自动生成出来。" 换句话说：这门课真正的杠杆在 Stage 1。