JobRadar 架构设计

设计原则

JobRadar 采用 Agent 原生的模块化单体架构。Django 负责公网产品外壳、用户系统、业务数据和运行记录；OpenAI Agents SDK 负责 Agent 循环、工具调用、结构化输出、运行状态和追踪；Celery Worker 承载耗时运行。生产环境各模块共享 PostgreSQL，避免为了展示效果提前拆分微服务；第一阶段本地开发和自动化测试允许使用 SQLite，并通过 PostgreSQL 集成验证保证迁移兼容性。

目标架构

flowchart LR
    USER["公网用户"] --> PROXY["Nginx / Caddy 与 HTTPS"]
    PROXY --> WEB["Django 登录与 Agent 工作台"]
    WEB --> APP["Django 业务与运行管理"]
    APP --> DB[("PostgreSQL")]
    APP --> REDIS["Redis 任务队列"]
    BEAT["Celery Beat"] --> REDIS
    REDIS --> WORKER["Celery Agent Worker"]
    WORKER --> RUNNER["Agents SDK Runner"]
    RUNNER --> AGENT["岗位研究 Agent"]
    AGENT --> TOOLS["类型化 Function Tools"]
    TOOLS --> COLLECT["Playwright / HTTPX"]
    TOOLS --> ENRICH["企业信息与联网调查"]
    TOOLS --> RULES["规则筛选与权重计算"]
    TOOLS --> DB
    RUNNER --> TRACE["Tracing 与运行事件"]

Agent 定位

Agent 不是对岗位描述进行一次总结的接口，而是任务执行主体。一次完整运行需要接收目标和边界、自主选择工具、根据工具结果继续调查，并在证据不足或涉及敏感操作时暂停，最终输出结构化结果和完整轨迹。

第一版只设置一个“岗位研究 Agent”。采集器、企业查询、评分器和数据库不是独立 Agent，而是 Agent 可以调用的确定性工具。只有评测证明单 Agent 在职责或指令复杂度上不可维护时，才拆分专家 Agent 并使用正式 handoff。

Agent 运行边界

使用 OpenAI Agents SDK 的 Agent 和 Runner 实现运行循环，不自行模拟工具调用循环。
使用 function_tool 暴露业务能力，输入和输出采用明确的数据模型。
Django 请求只创建任务；长时间 Agent Run 由 Celery Worker 执行。
运行上下文携带用户、任务、规则版本和数据库会话边界，不把敏感凭据写入提示词。
Agent 最终输出使用结构化模型校验，数据库写入仍通过受控工具执行。
保存 run、turn、tool call、tool result、trace、耗时、token 用量、异常和人工确认状态。
第一版不使用 SandboxAgent；业务只需受控网络和数据库工具，不需要开放 Shell 或任意文件执行能力。

模型服务商配置边界

普通用户通过 Django 服务端页面维护自己的模型服务商配置，配置之间按用户归属隔离。
服务商公开协议、基础地址和推荐模型由代码预设；页面不能提交或覆盖预设地址，避免形成任意网络请求入口。
OpenAI、Claude、DeepSeek、Gemini、阿里云百炼、智谱、硅基流动及常见聚合平台按各自协议验证模型目录；验证请求不发送对话内容，不产生模型推理调用。
API Key 使用独立部署主密钥进行可逆加密，数据库、页面、日志、Agent 上下文和运行摘要均不得出现明文。
Azure OpenAI、AWS Bedrock 及需要地域、部署、IAM 或业务空间参数的平台只展示接入状态，不得误标为只填 API Key 即可使用。
真实 Gateway 在执行边界按当前用户解析默认服务商、模型和密钥；密钥不会进入 AgentExecutionRequest。

用户与权限边界

使用 Django 内置认证、Session 和密码管理能力。
普通用户拥有个人画像、搜索任务、规则、Agent Run 和岗位操作记录。
用户私有数据通过所属用户字段隔离，工具执行前统一校验数据归属。
管理员通过 Django Admin 维护全局站点配置、工具开关和异常数据。
第一阶段仅区分普通用户与管理员，不建设复杂 RBAC。
默认由管理员创建账号并关闭公开注册。

Agent 处理链路

用户提交岗位研究目标，Django 创建 Agent Run 并投递异步任务。
Agent 读取用户画像、目标网站、硬性条件、评分权重和运行预算。
Agent 调用搜索与采集工具获取候选岗位，工具保存原始证据。
Agent 调用标准化、去重和硬规则工具，剔除确定不符合的岗位。
Agent 按需调用企业查询和联网调查工具补足证据。
Agent 调用结构化分析及确定性评分工具，得到维度分数和风险项。
证据冲突或置信度不足时标记待人工复核，不强行下结论。
Agent 输出研究报告，持久化工具保存结果、引用和运行状态。
WebUI 展示推荐结果、Agent 轨迹、工具调用和失败节点。

模块边界

Agent 运行模块

定义 instructions、运行上下文、工具集合和结构化输出契约。
控制最大轮次、时间预算、工具预算和失败恢复策略。
使用 SDK tracing 观察运行，并同步关键事件到本地数据库。
通过 guardrail 和人工确认限制高风险行为。
可以按内容和分析版本复用结果，但不引入向量检索兼容层。

工具层

一个工具只承担一种可描述、可测试的业务能力。
工具负责真实外部操作，Agent 不得声称执行未发生的查询或写入。
写工具必须幂等，记录调用来源、输入摘要、输出摘要和异常。
工具只返回下一步所需数据，避免把敏感信息放入模型上下文。

采集与企业研究工具

优先使用网站允许访问的接口或普通 HTTP 请求，动态页面才使用 Playwright。
每个网站独立实现适配器，并输出统一的原始岗位对象。
企业结论保存来源、证据摘要、获取时间和置信度。
多来源冲突、主体不明确或置信度不足时请求人工复核。

规则与评分工具

硬性条件和最终加权公式由确定性代码执行。
每个维度保存原始分、权重、加权分和判断依据。
权重或规则变化时创建新版本，历史结果仍可回溯。
Agent 不能绕过规则工具或自行生成最终分数。

数据边界

用户、个人画像及数据归属
招聘网站、搜索任务与采集批次
原始岗位、标准化岗位与企业证据
筛选规则、评分配置及其版本
Agent Run、运行事件、工具调用和结构化输出
Agent 指令版本、工具版本、模型配置和评测结果
收藏、忽略、投递、面试和人工复核记录

部署边界

web       Django Web 服务
worker    Celery Agent Worker 与 Agents SDK Runtime
beat      Celery 定时调度
postgres  PostgreSQL
redis     Redis
proxy     Nginx 或 Caddy 反向代理及 HTTPS 终止

公网只开放反向代理的 HTTP/HTTPS 端口。Django、PostgreSQL 和 Redis 位于容器私有网络，并配置 HTTPS、安全 Cookie、可信来源、登录限流、密钥注入、日志审计和数据库备份。

6.9 KiB Raw Blame History