设计理念

简洁高效，从传统招聘系统构架开开始

这样做的好处是，用户可以没有心智负担的立即开始使用新的系统，做到平滑过度；
而我开发这个系统，从传统架构开始，对比全新的革命性的设计，要相对简单的多，也有清晰的着手点。
构建一个完整流程的的招聘系统，作为基座，实现传统招聘流程管理和数据记录。
构建的过程中，可以分解并工程化实现每一个招聘环节，再将所有招聘环节逐个智能体化。
最终，将所有的招聘智能体整合到一起，形成一个完整的大智能体招聘系统。

逐步向招聘的Copilot形态演进

开发一年多来，正是借助AI编程的辅助力量，我才能完成这个项目的Beta版本。
这一年多来，是我自我学习成长的过程，同时也是大模型成长的过程；这似乎是人脑和智脑比肩进步的一个剪影，相映成趣。
在这个过程中，我深刻感受到大模型自身快速且明显的提升，因此确信自主智能体发展的前景。
但就目前的现状，大模型仍然有一定的局限性，例如幻觉、推理能力不足等，真正的完全自主的智能体实现还有一段路途。
所以，从功能性的工程构建，到逐步采用Copilot的中间形态，这是人工智能系统发展的必经这路。

全自主智能体将是可以预见的终极形态

尽管大模型作为底座，还有着这样那样的局限，但是随着不断地迭代，按照用户需求，智能体自主产生智能体的形态，或许是人工智 能发展的终极形态，至少也是一个不可忽视的关键演进节点。
因此，招聘系统的终极目标，也一定是全自主的智能体。只是到那个时候，我们会普遍看到，人工智能代替了人类的大部分工作；而智能 招聘系统的存在，似乎也会被人工智能革命了。
当然，这是一个未来学的话题，不做展开。

系统模式

一开始便选择Hard模式，试图实现不同招聘用户身份角色的需求，比如甲方用户（企业或组织招聘HR）、乙方（招聘供应商，如猎 头、RPO、蓝领招聘等）、Soho用户（个人或小团体招聘）。
这条路径，显然是贪心照顾绝大多数的需求，但在系统的设计上，会有复杂的角色权限管理，以及各种角色的不同流程设计。想要兼容并 包，这对于系统构建来说，是一个巨大的挑战。也因此，在系统Beta上线时，免不了存在一定的Bug，需要不断的迭代优化，也需要社群 的包容、参与、反馈和支持。
以上这点，对于开发者至关重要。

如何使招聘变的有趣？

当工程化的基础打好了，我们再逐步添加打磨有趣的要素。毕竟，我们可以直接把大模型当人来看待，尽管它会犯错，但他却可以是一个 有趣的人，可以轻松愉悦的与我们合作。
当然，我自己也还不是个有趣的人，写这些文章时，我都试图用有趣的方式来呈现。无奈，作为摩羯座的我，崇尚理性似乎是非常坚固的 基因，文章的风格难免一本正经，见谅见谅。
这一点的难度和挑战又升级了，我们先暂做未来的方向，也期待社群中能得到这方面非常独特的支持。

副产品

除了招聘系统，还会有很多其他的副产品，比如人岗匹配的智能体（规划中），其实也很容易得转化为应聘者找工作的智能辅助。可能性 很多，提前先做个预告，万一做出个副产品出来，大家也别太觉得我不务正业，哈哈。

技术栈

智能体框架：Langchain + Langgraph
前端：vue3 + vite + element-plus
后端：django + drf + django-ninja（逐步由ninja替换掉drf）
数据库：pgsql + redis + elasticsearch
GraphRGA：neo4j（学习规划中）
部署：docker + nginx + uvicorn
有技术大拿，对项目刚兴趣的，也欢迎加入指点，当然暂时也是无偿奉献。

运营模式

对这点，我异常纠结。矛盾点在于，项目的初心，就像我在《缘起》篇中所讲，多少有些“大庇天下寒士俱欢颜”的情怀，让天下没有难做 的招聘嘛；但同时也要考虑时间成本投入，以及“为稻粱谋”的无奈。总之，“寻找意义”和“寻找食物”，这两个人类的命题，矛盾的交织在 我这里，“使我不得开心颜”啊，哈哈。
所以，在我尚未想清楚之前，项目将会以“非盈利”的方式运营，也希望社群力所能及之士，能够提供一些支持和建议。
脸红的提醒一下，主页有“打赏”二维码，咳咳。

关于本站

未来会开篇更多关于招聘的专业问题的文章，并同时开通微信公众号，欢迎关注。