这是我第一次参与AI产品的研发，AI产品的研发过程确实和传统的软件不同，尤其是在AI快速发展的这两年，社区不断在Agent框架，模型能力上面取得进步。
在开发过程中也是在做不断的调整和预研，我们做的是渗透测试这个垂直领域的Agent，有这么几个典型特征:
1.渗透测试任务持续时间长
2.渗透测试起点（目标站点）和终点（找出目标站点存在的漏洞）已知，中间过程完全是未知的
3.渗透测试过程可能会对客户系统造成破坏，关键环节需要人工审批
从抽象层面来看，这其实是和写代码的过程是非常相似的：
1.完整开发一个系统需要的时间也比较长
2.开发的目标是已知的，过程未知，有多种实现方式
3.危险的命令，例如rm 删除文件，curl访问外网之类的
我们在设计和实现渗透测试Agent的时候也参考了很多像claud code，codex，opencode这些优秀的Harness框架的设计，用来构建稳定运行的渗透测试Agent底座。学习这些现有的被市场验证过的产品是很有必要的。
做产品还需要考虑到不同的客户需求，我们的客户主要是政府，运营商，金融行业，有些客户很看重数据安全，需要本地部署的模型，有些客户能够接受公网模型，这就引出了第一个挑战，要求我们的产品既可以在公网的大参数量模型上面表现优异，也需要在本地部署的像Qwen系列27B、35B这种参数量的模型上面同样有良好的渗透测试效果。有时候做产品并不是哪家模型强就用哪家的，客户需求是第一位。
除了拉齐本地小参数量模型这个挑战之外，系统还要具备应对模型能力变化对渗透测试效果，渗透测试时间影响的能力，可能有读者会有疑问，模型能力提升难道还对系统有影响吗，不应该是变得更好吗？从直观上推理确实是这样，放在实际中就会有意想不到的事情发生，比如，最近新发布的Qwen3.8-27B，思考过程明显变得更长，非要在思考中尽可能找出答案，迟迟不肯行动，导致原本只有几个小时的渗透测试时间，瞬间变成了1-2天，像这样因为模型升级带来的变化数不胜数。
并且，我们在开发中还需要考虑到模型能力提升，我们的提示词是否会成为限制模型能力的囚笼，我们需要考虑到模型能力提升这个未来的客观现实，不仅要保证现在的效果，还要尽可能的为模型腾出自由探索的空间。
对于渗透测试这样高度自由开放的任务场景，并且是针对客户的真实业务系统，安全边界和人工授权、审批这些步骤必不可少，这关系到Agent会不会直接破坏客户业务系统，这是系统是否被客户接受的关键。解决了这个问题之后，客户又会有更进一步的需求，希望整个渗透过程高度自主，不要老是让客户审批，下达任务，确认好边界之后，Agent直接闷头干完，最后给出报告，中间不要再来打扰客户，我们在使用claude code写代码时也是这样，希望AI中间不要打扰我们，自己干完，不需要盯着。这个安全边界和审批的设计是一个相当有挑战性的任务，它决定了系统是否好用。
在Agent产品的开发中，不停的变化是常态，很多时候需要紧跟当前最新的开源项目，好的思路，经过验证后后应用在产品中解决当前存在的问题，不限于：更好的Agent调度策略，更好的上下文管理，这关乎系统的运行效率和成本