MedHack：开源 AI Agent 健康应用

Auth0 for AI Agents 挑战赛投稿

这是我对 Auth0 for AI Agents 挑战赛的投稿。

MedHack 是一个 AI 驱动的健康协助平台，旨在让任何人都能获取基础医学指导和个性化营养规划——尤其是在专业医疗资源难以获得、费用昂贵或令人困惑的环境中。

该应用有两个核心 AI agents：

MedScan 诊断 Agent 该 agent 分析医学影像，如 X 光、CT 扫描、MRI，甚至皮疹或可见伤口的照片。它帮助用户在就医前理解身体可能发生的情况。它不替代医学专家——它只是提供早期的清晰认知，减少焦虑，帮助用户在寻求治疗时提出更好的问题。

饮食规划 Agent 这个 agent 不是生成通用的饮食表，而是进行交互式操作。它询问年龄、活动量、偏好、医学状况、日常作息，甚至预算。然后它会生成一份个性化的每周饮食计划，包含热量目标、营养成分分解、购物清单和持续的基于对话的调整。该结构化计划可以下载为 PDF 或直接通过邮件发送给用户。

在线演示：https://med-hack.vercel.app/ Github 仓库：https://github.com/kris70lesgo/Medhack

观看视频查看 medhack 的在线演示

1. 登陆页面/主页 AI 驱动的个人健康助手，结合诊断 + 营养规划

2. MedScan 用户上传 X 光、皮肤图像或医学报告进行分析。

3. 饮食规划 用户提供年龄、体重、饮食偏好、医学状况和目标。

智能对话屏幕 Agent 提出澄清问题以精确定制计划。

7 天饮食计划预览 完整的、结构化的 7 天饮食计划即时生成

PDF 下载 计划可以安全地下载为格式化 PDF

邮件集成 最终计划也通过邮件发送以方便使用

Auth0 角色和操作 基于角色的访问区分免费和高级功能访问。自动化的角色分配确保顺畅安全的入职流程

问题：医疗指导今日的困境

现在的医疗保健指导存在碎片化和效率低下的问题：

• 人们依赖 Google 搜索症状，这经常导致困惑和焦虑。
• 在线饮食计划是通用的，未根据健康状况、目标或日常作息个性化。
• 咨询医生或营养师费用昂贵，通常需要等待时间。
• 医学报告、扫描或皮疹、骨折等图像在没有专家帮助的情况下难以解释。
• 没有统一的平台能以个性化、简便的方式结合医学洞察 + 生活方式指导。

结果是，许多人最终会：

• 做出不健康的饮食决定
• 误解他们的症状
• 或完全忽视健康建议，因为感到不知所措。

解决方案：MedHack - 你的 AI 健康伙伴

MedHack 在一个平台上提供即时、个性化、可行的健康指导。

1) MedScan — 基于 AI 的医学理解

• 上传 X 光、报告或皮肤图像
• AI 分析病情并用简单的语言解释
• 提供可能的原因和建议
• 鼓励知情决策——不是盲目自诊

2) 饮食规划 Agent — 个性化膳食规划

• 输入你的年龄、体重、生活方式习惯、预算和目标

• agent 提出后续问题以了解你的真实日常作息

• 生成定制的 7 天饮食计划：

  • 营养均衡
  • 基于个人限制（素食、过敏症等）
  • 针对减肥、增肥或通用健身量身定制

• 计划可以立即下载为 PDF 或通过邮件发送

安全设计（Auth0 集成）

这确保该应用能够负责任和安全地扩展。

• 用户身份验证保护个人健康数据
• 基于角色的访问让免费用户尝试基础功能
• 高级角色解锁高级扫描和详细饮食规划
• Auth0 Actions 自动化角色分配和安全功能访问 这使 MedHack 实用、值得信赖，并准备好投入实际使用

我如何使用 Auth0 for AI Agents 来保护 MedHack

MedHack 处理个人医学数据，因此安全和受控的访问至关重要。我集成了 Auth0 for AI Agents 来处理身份验证、授权和工具访问权限。

1) 用户身份验证

用户使用 Auth0 的托管登录页面登录。在 middleware.ts 中，我保护私有路由：

// middleware.ts
import { auth0 } from "@auth0/nextjs-auth0";

export default auth0.withMiddlewareAuthRequired();

这确保只有经过身份验证的用户才能访问仪表板、饮食规划或 MedScan 功能。

2) 基于角色的访问控制（RBAC）

角色	访问权限
free_user	基础 MedScan + 简单饮食建议
pro_user	完整饮食生成器、详细扫描推理、PDF + 邮件导出

角色在 Auth0 仪表板中分配（或当用户升级时通过 Actions 分配）。

代码中定义的角色（auth0-fga.ts）

export const roles = {
  FREE_USER: {
    name: 'free_user',
    permissions: [
      "use:vision_agent",
      "read:health_data"
    ]
  },
  PRO_USER: {
    name: 'pro_user',
    permissions: [
      "use:vision_agent",
      "use:diet_agent",
      "read:health_data",
      "write:health_data",
      "export:pdf",
      "send:email"
    ]
  }
};

3) 将权限注入 JWT（Auth0 Action）

我添加了一个 Auth0 登录后 Action，使用户令牌包含权限：

exports.onExecutePostLogin = async (event, api) => {
  const namespace = "https://medhack.ai";
  const role = event.authorization?.roles?.[0] ?? "free_user";

  const permissions = role === "pro_user"
    ? roles.PRO_USER.permissions
    : roles.FREE_USER.permissions;

  api.idToken.setCustomClaim(`${namespace}/permissions`, permissions);
  api.accessToken.setCustomClaim(`${namespace}/permissions`, permissions);
};

4) 服务器端权限强制执行

在运行任何 agent 或 API 调用前，我验证权限。

// lib/authorization.ts
import { auth0 } from "@auth0/nextjs-auth0";

export async function withAuthorization(requiredPermission: string) {
  const session = await auth0.getSession();
  const userPermissions = session?.user?.["https://medhack.ai/permissions"] ?? [];

  if (!userPermissions.includes(requiredPermission)) {
    throw new Error(`Forbidden: Missing Permission → ${requiredPermission}`);
  }
}

使用示例（保护饮食 Agent API）：

// app/api/agents/diet/route.ts
import { withAuthorization } from "@/lib/authorization";

export async function POST(request: Request) {
  await withAuthorization("use:diet_agent");

  // ...run AI agent logic
}

✅ 免费用户无法调用饮食 agent。✅ 专业用户可以。

5) 令牌保险库：安全工具访问

当 agents 调用外部 API（OCR、视觉、食品营养搜索、邮件发送）时，我使用 Auth0 令牌保险库，所以：

• 令牌永远不会到达前端
• AI agents 获得临时作用域访问

import { getAccessToken } from "@auth0/nextjs-auth0";

const { accessToken } = await getAccessToken({
  scopes: ["send:email", "export:pdf"]
});

6) 细粒度授权风格的所有权规则（用户数据隐私）

每个用户只能访问他们自己生成的计划和扫描：

export function canAccessResource(resourceOwnerId: string, currentUserId: string) {
  return resourceOwnerId === currentUserId;
}

✅ 没有人可以查看或下载其他人的医学计划或扫描。这在功能上类似于 Auth0 细粒度授权（FGA）模式。MedHack 是安全、可扩展的，并准备好安全部署到公网。

经验教训和关键收获

💭 开发回顾

7 个主要挑战与解决方案

问题：Qwen2.5-VL-72B 在生产中失败（404：免费层找不到模型） 解决方案：实施自动回退系统，包含 3 个模型（Gemini → Claude → Llama） 学习：在部署前始终研究模型可用性；先在本地测试

问题：错过了 JWT 自定义声明的命名空间要求（声明未出现在令牌中） 解决方案：在 Auth0 Action 中添加命名空间：api.idToken.setCustomClaim(${namespace}/permissions, ...) 学习：身份验证应该首先设计，而不是后来改装

问题：最初在 localStorage 中检查权限（用户可以伪造） 解决方案：将所有权限检查移至后端，通过 JWT 自定义声明验证 学习：永远不要相信客户端安全性；后端必须验证每个请求

问题：API 密钥跨用户共享（无法追踪使用或撤销访问） 解决方案：创建 TokenVault 类以按用户隔离密钥，在访问前验证所有权 学习：从第一天开始考虑数据所有权；每个资源都需要一个所有者

问题：cookies().get() 在 v14 中有效，但在 v15 中失败（必须是 awaited） 解决方案：更新所有 cookie 访问：(await cookies()).get('demo_role') 学习：现代框架快速演进；仔细阅读发布说明

问题：单个模型失败 = 500 错误；没有优雅降级 解决方案：通过 try-catch 循环尝试 3 个模型；有意义的错误消息；详细的日志记录 学习：韧性胜过简洁；总是有备用方案

问题：Med Scan 在本地有效，但在生产中失败（未定义的 API 密钥） 解决方案：创建 /api/debug/env 端点来诊断问题；在部署前添加所有变量 学习：尽早创建诊断端点；没有可见性无法调试生产环境

关键学习：

• 模型不同 → 尽早测试多个模型
• Prompt 工程很重要
• 回退系统至关重要
• 上下文改进结果显著
• Auth0 很强大但需要理解 OAuth2 基础知识
• JWT 令牌是自含的证明（加密签名）
• HTTPOnly cookies 防止 JavaScript 盗窃
• 细粒度授权需要仔细规划
• 后端绝不信任客户端 → 验证所有内容
• 类型安全（TypeScript）防止运行时错误
• 日志是你进入生产的窗口
• 全面的错误处理改进 UX
• 安全不是可选的 → 从第一天开始构建
• 后端绝不信任客户端 → 验证所有内容
• AI 回退至关重要 → 永远不要依赖单一模型
• JWT 令牌优雅 → 自含的、加密签名的
• 类型安全捕捉错误 → 为较大项目使用 TypeScript
• 日志节省时间 → 简单的日志启用生产调试
• 韧性胜过简洁 → 优雅地处理故障

✅ Auth0 集成比预期简单 ✅ 细粒度授权规模扩展得很好 ✅ 全面的错误处理改进了 UX ✅ 清晰的代码组织实现了快速开发 ✅ AI 回退消除了停机时间 ✅ 安全的令牌保险库防止密钥泄露

如果重新来会怎么做

• 首先开始 Auth0 设置（这是基础）
• 尽早创建架构图
• 从第一天开始测试错误情况（不仅仅是快乐路径）
• 在生产前设置监测
• 尽早规划数据库架构

挑战：7 个主要挑战已解决

尝试的模型：3 种方法

权限：3 个角色中定义的 10 个

安全层：7 个（身份验证、授权、令牌保险库、审计日志等）

代码行数：~3,000+

生产问题：1 个（env 变量）- 用调试端点在 30 分钟内修复

类似项目的建议

构建 AI 应用程序：

• 尽早测试多个模型
• 从第一天开始实施回退策略
• 记录哪个模型成功
• 选择 Auth0 或类似的（不要自己构建）
• 在编码前规划权限
• 永远不要只在客户端检查权限

全栈开发：

• 从架构图开始
• 创建诊断端点
• 在第一次部署前设置 env 变量
• 添加新变量后重新部署
• 更新 Auth0 回调 URL
• 彻底进行本地测试

伟大的产品是在以下交集处构建的：

• 清晰的架构（组织有序、可维护的代码）
• 周到的安全性（安全优先的决策）
• 弹性系统（优雅的故障处理）

最好的学习来自于挑战。每个问题都教会了我一些使我成为更好开发者的东西。

如果我能给出一个建议："将安全和韧性构建到基础中。尽早创建诊断工具。测试完整流程。记住：如果你能看到发生了什么，你可以调试任何东西。"

MedHack 证明，通过适当的架构、周到的安全性和弹性系统，你可以快速构建令人印象深刻的 AI 应用程序。

某些评论可能仅对已登录访问者可见。登录以查看所有评论。

如需进一步行动，你可以考虑屏蔽该用户和/或举报滥用。