AI Agent 越来越多却找不到：Search2o 用搜索框编排企业任务
很多团队已经为报表、客户支持、代码查询和内部运维分别做了 Agent，但使用方式仍然像一张不断膨胀的命令清单：记住每个 Agent 的名字，打开对应页面，再手动准备上下文。Search2o 提供了另一种思路：把任务型 Agent 做成可搜索的能力，用户直接用自然语言提问，由搜索层匹配并运行合适的 Agent。
它不是一个新的基础模型，也不是把所有企业系统重新封装成聊天机器人。根据项目公开说明，Search2o Agent Server 是一个无状态、异步的 Python 服务，带 REST API 和 Web GUI；Agent 在组织自己的服务器中运行，平台负责草拟、验证、发布和检索。项目目前处于 open beta，代码可通过 PyPI 安装，但服务器采用 source-available proprietary license，不应简单称为 MIT 开源项目。
先理解它的工作方式
Search2o 的核心单位不是“一个万能 Agent”，而是许多个边界清晰的任务 Agent。官方入门文档建议，一个 Agent 通常连接一到两个企业系统，专注解决一种具体问题。例如：
- 读取工单系统，回答某个客户的历史问题；
- 查询数据仓库，生成本周销售异常摘要；
- 读取代码仓库和发布记录，说明某个版本为何回滚；
- 调用内部文档系统，整理一项合规检查所需的证据。
管理员先为 Agent 写清楚自然语言描述，再把它验证并发布。用户在搜索框输入问题后，系统根据描述选择匹配的 Agent，运行它并返回结果。这样做的价值不在于减少 Agent 数量，而在于把“选择哪个 Agent”从人的记忆任务变成了检索任务。
这也解释了它与普通聊天机器人的区别：普通聊天窗口往往只有一个入口，Search2o 更像一层能力目录。每个 Agent 可以拥有自己的模型配置、连接器和任务边界，搜索只是把合适的能力暴露给使用者。
安装一个本地 Agent Server
PyPI 页面给出的安装方式是：
pip install search2o
启动前需要设置许可证密钥：
SEARCH2O_LICENSE_KEY=your-license-key search2o
Windows PowerShell 则使用：
$env:SEARCH2O_LICENSE_KEY="your-license-key" search2o
安装包包含 GUI，而项目仓库说明服务器代码与 GUI 项目是分开的。启动后，默认可以打开 http://127.0.0.1:9020/ui。首次使用时，在登录窗口选择 New user / Forgot password，输入创建账号时使用的邮箱和邮件验证码，再设置密码。
如果团队使用自托管模型，公开说明列出了 Ollama、vLLM 和 SGLang；这些场景不需要云厂商 API Key。若使用 OpenAI、Anthropic 或 Gemini，则在启动前设置相应的 OPENAI_API_KEY、ANTHROPIC_API_KEY 或 GEMINI_API_KEY。不要把密钥直接写进文章、仓库或前端配置。
服务还会提供 OpenAPI Schema：
http://127.0.0.1:9020/openapi.json
同时有 Swagger UI 和 ReDoc 入口，适合先通过浏览器查看 API，再决定是否接入内部自动化流程。
用 JSONC DSL 管理可复用任务
HN 展示信息把 Search2o 描述为可以用 JSONC DSL 构建可搜索 Agent 的平台。实际落地时，建议把 DSL 当作可审查的配置，而不是让每个人随意创建“万能助手”。一个稳妥的 Agent 定义至少应明确四件事：它解决什么问题、能访问哪些系统、输出什么格式、遇到权限或数据不足时如何停止。
例如，财务异常 Agent 可以只读销售数据和工单摘要，输出固定的异常列表；它不应该同时拥有删除数据、修改账单或发送外部邮件的权限。先把任务拆窄，再用搜索描述连接到正确的 Agent，比给一个 Agent 堆叠几十个工具更容易测试和审计。
官方流程是进入 Agents → Drafts 创建草稿，选择 LLM profile，然后用 Draft with AI 协助生成初稿。完成后先验证，再发布，并补充让搜索能够匹配的自然语言描述。建议在发布前准备一组固定测试问题，检查相似任务是否会误路由到同一个 Agent。
一个适合团队的试用流程
第一次试用不要直接接入生产写权限，可以按下面顺序推进：
- 选择一个只读系统和一个边界明确的问题，例如“找出本周失败的部署并按服务分组”。
- 创建草稿，明确输入来源、输出格式和最大查询范围。
- 用几条同义问题测试搜索匹配，记录误匹配和没有结果的情况。
- 验证结果后发布，只给 Agent 最小必要权限。
- 再让团队成员使用自然语言提问，观察他们是否能在不记住 Agent 名称的情况下得到正确能力。
如果需要让编码 Agent 使用同一套能力，公开材料还提供了 search2o-skill 项目，说明这些 Agent 可以通过 Claude Code 使用。不过这类集成仍要单独验证权限、上下文和版本兼容性，不能因为存在 Skill 仓库就假设所有 CLI 都自动可用。
自托管前要注意什么
Search2o 的“搜索即执行”体验很适合企业内部能力目录，但它也会放大权限设计问题。搜索层一旦把请求路由到错误的 Agent，错误结果可能比“没有找到工具”更危险。因此每个 Agent 都应采用最小权限、只读优先和可追踪输出；涉及写入、审批或外发消息的动作，应保留人工确认。
部署层面，优先把服务放在内网、VPN 或明确的反向代理之后。不要因为 GUI 绑定了本机地址，就把它直接映射到公网；也不要把许可证密钥和模型 API Key 放在前端代码中。对于生产环境，还应补上备份、日志保留、连接器凭据轮换和 Agent 版本回滚方案。
Search2o 最适合已经拥有多个内部自动化能力、却苦于入口分散的团队。它的亮点不是“再做一个聊天窗口”，而是尝试把 Agent 变成可检索的组织能力。若你的问题只是偶尔运行一个脚本，普通 CLI 更简单；若你需要在多个业务系统之间建立自然语言入口，同时又愿意认真设计权限边界，那么这种搜索驱动的 Agent 目录值得小范围试用。
相关链接