廣東
來源：新智元
【導讀】傳統API集成已死！在這個Agent滿地跑的時代，被低估的搜索終于迎來了第四次范式轉移。AnySearch的問世，讓Agent告別了單一的網頁總結功能，轉而通過獲取可信的結構化信息，真正具備觸達并連接現實世界的能力。
2026年，AI Agent的能力邊界，正以月為單位向外擴張。
寫代碼、做研報、跑安全審計...... 半年前，還需要人類手把手帶著做的任務，Agent現已能獨立完成八成以上。
但一個尷尬的事實是，Agent正在被一個看似不起眼的環節卡住：搜索！
讓AI幫你查一家公司的股權結構，它只能給你官網簡介；
讓它找一段生產級代碼實現，它甩給你一篇Medium入門教程；
讓它分析一個可疑IP的威脅情報，它只能搜出幾篇科普文章。
不是AI搜索不夠快，是搜索「看不到」。
如今，這個問題，終于有人在認真解決了！
上線一周，AnySearch引爆全網
5月11日，一款名為AnySearch的產品在海外正式上線。
它給自己的定位很明確：AI時代的「搜索基礎設施」，專為AI Agent打造統一的高質量搜索入口。
上線一周，AnySearch在海外開發者圈徹底炸了。
它迅速登陸GitHub、ClawHub、skills.sh、SkillHub、Glama等多個開發者生態平臺，在技術社區和插件商店中獲得了穩定的下載量和互動量。
今天AnySearch登上skills.sh熱榜TOP1
一位AI大佬Guri Singh在X上力薦AnySearch，他是這么評價的——
如果你在2026年構建AI Agent卻沒有使用這個，那你就像是閉著一只眼睛在搜索。
另一位AI博主還上手試用了下，將AnySearch與Brave、Perplexity做了對比，顯然AnySearch輸出的結果更豐富。
Bishal Nandi驚嘆道，AnySearch可以通過大模型獲取Reddit論壇、代碼倉庫、股票市場等多種信息。
在Reddit上的好評，同樣如潮。
無獨有偶，一位Reddit網友做了一個不同AI搜索相同問題的小實驗，AnySearch開出的「盲盒」屬實太驚艷了。
有人對此回應道，如今檢索信息和來源選擇的重要性，和模型能力的不相上下。即便是同一款模型，更強大的搜索/上下文，可以讓它更具實用性。
AnySearch就像開了「天眼」一樣，可以看到許多被埋沒在互聯網不同地方的內容。
AnySearch究竟有多能打？
在基準測試中，AnySearch在準確性和響應延遲兩個維度，均優于同類AI搜索產品Parallel和Brave。
而且，在與同類Brave Search測試對比，結果顯示，AnySearch數據更完整、分析更深入、回答更全面。
但產品好不好，最終還要看實戰，畢竟， 搜索是一件「用了才知道差距」的事。
接下來，我們針對不同場景，看看AnySearch在實戰中戰斗力如何？
Skill安裝異常簡單！
在官網http://www.anysearch.com，點擊Install/安裝，復制安裝教程直接輸入Agent，部署完成。
場景 1：產品經理 — 競品調研
最近流行開始用Codex替換Claude Code。
作為普通用戶，我們想確認一下，這件事究竟靠不靠譜。
提示詞：
查OpenAI：最新估值與融資節奏、近三個月定價變動、iOS App Store用戶評分與差評焦點、Reddit社區口碑。特別是旗下的Codex。
輸出：
綜合如下(截至 2026-05-17):
1. 最新估值與融資節奏
2026-03-31:完成史上最大私募,$1220 億承諾資本,投后估值 $8520 億。亞馬遜($500 億,$150 億即付 + $350 億待 IPO/AGI)、英偉達、軟銀領銜(三者合計約 $1100 億);紅杉/Thrive/貝萊德/黑石跟投,微軟參與未披露。
循環信貸擴至約 $47 億(未動用);首次向個人開放認購(募 >$30 億),納入 ARK ETF(ARKK 約 3% 敞口)。
IPO:市場預期最早 2026 Q4(可能納斯達克),但 CFO Sarah Friar 私下認為 2026 條件不足;需先完成營利化法律過渡 + 首披經審計財報。
估值爭議:有雙押投資者稱支持這輪需假設 IPO 估值 >$1.2 萬億;對比 Anthropic 估值僅 $3800 億、年化收入 2026-03 已飆至 $300 億(OpenAI 2026-02 為 $250 億,口徑不同),二級市場首次給 Anthropic 溢價。兩家均虧損,OpenAI 資本支出更激進。
2. 近三個月定價變動(Codex 重點)
04-02:Business $25→$20/席(年付);同日 Business/新 Enterprise 改 API token 計價(credits/1M tokens),舊"按消息"費率分批遷移。
04-09:新增 $100/月 Pro 檔,Codex 用量 5x Plus。
官方促銷(至 2026-05-31):Pro $100 → 2x(即 10x Plus);Pro $200 → 長期 20x Plus,5 小時高限 25x Plus 延續到 5-31。
Codex rate card 實測約 $100–200/開發者/月,方差大。
Sam Altman(約 05 月):30 天內給遷移企業 兩個月免費 Codex + 無縫遷移工具——直接搶 Claude Code 的企業遷移窗口。
3. iOS App Store 評分與差評焦點
累計評分約 4.72/5(52.4M 評論;iOS 4.8/5、~720 萬評分;臺區顯示 4.9/52 萬)。但近期情緒 "Frustrated" 25/100、趨勢下滑(Marlvel.ai,審計 2026-05-13,版本 1.2026.125)——歷史均分高,近評轉負。
差評焦點(按頻次):①訂閱/付費墻最突出(免費檔收緊引發差評潮、自動續費、"$20–40 不值")②"It used to be smarter"感覺降智/不一致 ③用量上限不透明 ④崩潰/網絡錯誤/語音斷連(近期
技術抱怨)⑤隱私(訓練數據、歷史不可刪,德法區尤甚)⑥過度拒答、VoiceOver 遮擋發送鍵 ⑦2026-04 iOS 登錄 403、重裝無法修復(疑風控收緊)。正面:語音模式、情感陪伴即便在 1 星里也常被夸。
4. Reddit / 社區口碑(Codex vs Claude Code)
QJC 分析 500+ Reddit 評論 + 36 次盲測:共識"Claude Code 質量更高但限額太快不可用;Codex 質量略低但能用一整天"。直接偏好 Codex 65%(點贊加權 80%),但 Claude Code 討論量 4x(基數更大)。盲測 Claude Code 勝 67%;SWE-bench 59% vs
56.8%,Terminal-Bench Codex 77.3% 完勝 65.4%,Codex token 效率約 4x,68% 開發者認為 Codex 首跑成功率更高。社區主流策略=兩個都用。
GPT-5.3-Codex:好評在 agentic 自主性(能自己跑數小時、邊測邊改);批評在"只會生成、不能像 GPT 那樣討論 R&D"、部分 Mac 不可用、懷念 4o()。
企業側:Ramp AI Index 2026-04 Anthropic 采用率 34.4% 首超 OpenAI 32.3%,Claude Code 成多團隊默認——Codex 免費遷移正是沖這個。
就一句話查 OpenAI 和 Codex，它給你把融資扒到每家出了多少錢、App Store 差評給你按頻次排好了、Reddit 上 Claude Code 和 Codex 的盲測勝率都拉出來了，連奧特曼說要「兩個月免費搶 Claude Code 遷移窗口」這種一手動態都沒漏。
這些東西你自己去查，至少翻四五個平臺，花一兩個小時。
它一個接口，幾秒鐘，全回來了，而且不是丟一堆鏈接讓你自己看，是整理好的，拿到就能用。
這就是 AnySearch 最強大的地方，一個入口，把散落在各個角落的信息一次性給你聚齊了。
場景 2：開發者 — 找生產級代碼實現
Claude Code如今已經取代了VS Code，成為開發者最重要的開發工具。
加上AnySearch這個Skill，能為開發者帶來哪些顯著的積極變化？
提示詞：
幫我看看生產環境里 Rust 異步連接池的背壓和健康檢查是怎么做的，要真實項目代碼，別給我教程示例。
輸出：
下面全部是我剛從真實倉庫拉下來的逐字源碼(非教程),今天 2026-05-17 的 main 分支,行號會漂,vendoring 時以你鎖定的 commit 為準。兩個對照實現:bb8(用得最多的異步池庫,djc/bb8)和 pgcat(PostgresML 線上部署的 Postgres 代理,postgresml/pgcat)。deadpool 作為第三種范式只給指針(我沒逐字讀就不杜撰代碼)。
背壓(backpressure)
bb8 —— 有界池 + Notify 阻塞 + 整體超時(無無界隊列)
bb8 —— 有界池 + Notify 阻塞 + 整體超時(無無界隊列)
bb8/src/inner.rs:83(get()),關鍵在拿不到空閑連接時:
let mut conn = match conn {
bb8 —— 有界池 + Notify 阻塞 + 整體超時(無無界隊列)
bb8/src/inner.rs:83(get()),關鍵在拿不到空閑連接時:
let mut conn = match conn {
Some(conn) => PooledConnection::new(self, conn),
None => {
wait_time_start = Some(Instant::now());
kind = StatsGetKind::Waited;
self.inner.notify.notified().await; // 池滿 -> 在這里掛起
continue;
let result = match timeout(self.inner.statics.connection_timeout, future).await {
Ok(result) => result,
_ => { kind = StatsGetKind::TimedOut; Err(RunError::TimedOut) } // 背壓信號
歸還連接時喚醒一個等待者(inner.rs:167):self.inner.notify.notify_one();(Notify 定義在 internals.rs:22)。設計:池有界,過載不排無界隊列,而是"阻塞到有連接或 connection_timeout 到點就 RunError::TimedOut"——天然 load-shedding,調用方被壓回到池容量。
pgcat —— 多副本故障轉移 + 熔斷 ban 作為背壓
src/pool.rs:768,get() 輪詢候選副本:
pgcat —— 多副本故障轉移 + 熔斷 ban 作為背壓
src/pool.rs:768,get() 輪詢候選副本:
while !candidates.is_empty() {
let address = match candidates.pop() { Some(a) => a, None => break };
if self.is_banned(address) {
if self.try_unban(address).await { force_healthcheck = true; }
else { continue; } // 跳過被熔斷的副本
let mut conn = match self.databases[address.shard][address.address_index].get().await {
Ok(conn) => { address.reset_error_count(); conn }
Err(err) => {
self.ban(address, BanReason::FailedCheckout, Some(client_stats)); // 取連接失敗即熔斷
continue;
// ...健康檢查通過則返回...
client_stats.checkout_error();
Err(err) => {
self.ban(address, BanReason::FailedCheckout, Some(client_stats)); // 取連接失敗即熔斷
continue;
// ...健康檢查通過則返回...
client_stats.checkout_error();
Err(Error::AllServersDown) // 所有候選耗盡 = 背壓/拒絕信號
每個副本底層用的就是 bb8(.databases[..].get().await),所以單副本繼承 bb8 的"有界+超時"背壓;pgcat 在其上疊加熔斷:取不到就 ban 該副本、轉下一個,全掛了才 AllServersDown。
deadpool(第三種范式,僅指針)
tokio::sync::Semaphore 持 max_size 個 permit,get()/timeout_get() 先 acquire 一個 permit——permit 即背壓閘門。倉庫 bikeshedder/deadpool → crates/deadpool/src/managed/(已重構成 workspace,mod.rs 僅再導出,實現分散在該目錄)。
deadpool(第三種范式,僅指針)
tokio::sync::Semaphore 持 max_size 個 permit,get()/timeout_get() 先 acquire 一個 permit——permit 即背壓閘門。倉庫 bikeshedder/deadpool → crates/deadpool/src/managed/(已重構成 workspace,mod.rs 僅再導出,實現分散在該目錄)。
deadpool(第三種范式,僅指針)
tokio::sync::Semaphore 持 max_size 個 permit,get()/timeout_get() 先 acquire 一個 permit——permit 即背壓閘門。倉庫 bikeshedder/deadpool → crates/deadpool/src/managed/(已重構成 workspace,mod.rs 僅再導出,實現分散在該目錄)。
健康檢查(health check)
bb8 —— 可選 checkout 校驗 + 歸還校驗 + 后臺 reaper
tokio::sync::Semaphore 持 max_size 個 permit,get()/timeout_get() 先 acquire 一個 permit——permit 即背壓閘門。倉庫 bikeshedder/deadpool → crates/deadpool/src/managed/(已重構成 workspace,mod.rs 僅再導出,實現分散在該目錄)。
健康檢查(health check)
bb8 —— 可選 checkout 校驗 + 歸還校驗 + 后臺 reaper
inner.rs:106:
if !self.inner.statics.test_on_check_out {
return Ok(conn);
match self.inner.manager.is_valid(&mut conn).await {
Ok(()) => return Ok(conn),
inner.rs:106:
if !self.inner.statics.test_on_check_out {
return Ok(conn);
match self.inner.manager.is_valid(&mut conn).await {
Ok(()) => return Ok(conn),
Err(e) => {
self.inner.statistics.record(StatsKind::ClosedInvalid);
self.inner.forward_error(e);
conn.state = ConnectionState::Invalid; // 丟棄,循環再取
continue;
Ok(()) => return Ok(conn),
Ok(()) => return Ok(conn),
Err(e) => {
self.inner.statistics.record(StatsKind::ClosedInvalid);
self.inner.forward_error(e);
conn.state = ConnectionState::Invalid; // 丟棄,循環再取
continue;
歸還時還會查 has_broken() 與 max_lifetime 過期(inner.rs:149-166);構造時 spawn 一個按 reaper_rate 的 interval_at 后臺任務做 idle_timeout/max_lifetime 回收并維持 min_idle(字段見
bb8/src/api.rs:145-188:test_on_check_out / max_lifetime / idle_timeout / reaper_rate / min_idle)。即:校驗非只在 checkout,后臺 reaper 也持續淘汰。
pgcat —— 限頻的 checkout 健康檢查 + 熔斷 + "絕不留壞連接"
src/pool.rs:807:健康檢查被刻意限頻(注釋原話 "Health checks are pretty expensive."):
let require_healthcheck = force_healthcheck
|| server.last_activity().elapsed().unwrap().as_millis()
> self.settings.healthcheck_delay as u128;
if !require_healthcheck { /* 直接返回,不查 */ return Ok((conn, address.clone())); }
run_health_check(:851)用超時包住一個"最便宜的查詢":
match tokio::time::timeout(
tokio::time::Duration::from_millis(self.settings.healthcheck_timeout),
server.query(";"), // 分號:跳過 query planner 的廉價探活
).await {
Ok(Ok(_)) => { /* ...checkout_success... */ return true; }
Ok(Err(err)) => error!("Failed health check ... {:?}", err),
Err(err) => error!("Health check timeout ... {:?}", err),
server.mark_bad("failed health check"); // 不把壞連接放回池
self.ban(address, BanReason::FailedHealthCheck, Some(client_info)); // 熔斷該副本
false
ban()(:909)對 FailedHealthCheck/FailedCheckout/MessageSend|ReceiveFailed 累加錯誤計數(判斷整 shard 是否宕),被 ban 的副本下次要走 try_unban 且 force_healthcheck=true 強制復檢才會再用。
生產可借鑒的取舍
健康檢查限頻:pgcat 按 last_activity > healthcheck_delay 才查,而不是每次 checkout 都查——探活有成本。bb8 給的是開關 test_on_check_out,默認關。
探活一定包超時:tokio::time::timeout(healthcheck_timeout, query(";"));探活查詢要廉價(; 跳過 planner)。
壞連接絕不回池:校驗失敗就 mark_bad/標 Invalid 丟棄重取,不返回給調用方。
過載轉成顯式信號:有界池 + 超時(bb8 RunError::TimedOut)/ 熔斷耗盡(pgcat AllServersDown),即 load-shedding,而非無界排隊。
熔斷 + 強制復檢再準入:不健康后端 ban 掉,解禁前強制 health check(pgcat),避免抖動反復打死。
后臺 reaper:健康/生命周期不能只靠 checkout 驅動,需獨立周期任務回收 idle/超齡并補足 min_idle(bb8)。
源碼出處:bb8 github.com/djc/bb8(bb8/src/inner.rs、internals.rs、api.rs);pgcat github.com/postgresml/pgcat(src/pool.rs);deadpool
github.com/bikeshedder/deadpool(crates/deadpool/src/managed/)。需要的話我可以把某一處(比如 bb8 reaper 全文、或 pgcat try_unban/is_banned 的熔斷恢復邏輯)再逐行拉出來過一遍。
你讓它找「Rust 異步連接池的背壓和健康檢查，要真實項目代碼」，它直接從 bb8、pgcat、deadpool 三個生產倉庫里把源碼逐行拉出來了，精確到文件路徑和行號。
這個才是關鍵，你用谷歌搜這個問題，大概率得到的是 Medium 教程和 README 里的 hello world 級入門代碼。
但真正寫代碼的人需要的不是教程，是「線上跑著的系統到底怎么處理的」。
AnySearch 直接幫你翻到了倉庫里的核心邏輯，而且不是把整個文件糊你臉上，是把背壓和健康檢查的關鍵段摘出來，三種方案橫向對著看，最后還給你總結了六條生產取舍。
對開發者來說，這個輸出拿到手就能指導設計決策，不用再自己去 GitHub 一個個倉庫翻。
這是場景 1 那種「聚合多平臺信息」之外的另一層能力，它不光能搜新聞和輿情，還能深入到代碼倉庫這種高度專業的信息源里，把真正有用的東西挖出來。
場景 3：投資人 — 標的公司盡調
投資人也是在日常任務中需要大量處理各種不同來源的數據和信息的「噪音受害者」，令人疲憊不堪。
AnySearch能否「拯救」投資人于水火之中呢？
提示詞：
查一下Anthropic：最新估值與股權結構、主要投資方及持股比例、已知訴訟或監管風險、核心專利布局、與OpenAI的營收和估值對比。
輸出：
本次自動檢索的數據互相打架且覆蓋不全,我先做可靠性分級,再按你的 5 個維度給結論。今天 2026-05-17。
1. 最新估值與股權結構
1. 估值時間線(按置信度標注)
2025-09 F 輪:$130 億融資,投后 $1830 億(36kr,已過時,約當年 3 月 3x;領投 Iconiq / Fidelity / Lightspeed,Altimeter / General Catalyst / Coatue 跟投)
2026 年初:約 $3800 億(本對話早前檢索口徑,二級市場需求超 OpenAI 并首付溢價)【中,已過時】
2026-05(財經媒體 2 天前):據報已就 ~$300 億融資達成條款,估值 ~$9000 億,首次反超 OpenAI(~$8520 億)【報道/條款階段,未官宣】
tmtpost(5-08)稱 $1.2 萬億 —— 與其它源沖突,單一離群值,不采信
→ 可信的是"一年內 183B→~380B→~900B 數倍跳升"的方向;9000 億是"達成條款"的報道而非交割,1.2T 別用。
股權結構 / 持股比例:公開不可得。 已知兩大戰略方為 Amazon 與 Google/Alphabet(各數十億美元、多輪,且含大額算力/云額度承諾——投資額≠股權%);財務方見上。Anthropic 未上市,cap table
未披露,搜索里也沒有任何百分比,我不編。要精確比例只能等招股書或可靠泄露。【明確缺口】
2. 訴訟 / 監管風險(方向可信,細節需查 docket)
版權/數據多線訴訟:作者集體案(訓練用書,Bartz v. Anthropic 一類)、音樂出版商案(Concord 等訴 Claude 輸出歌詞)、Reddit 起訴(未授權抓取)。具體進展/和解金額未在結果中,不臆斷。
消費端數據政策爭議:2025-09 起 Free/Pro/Max 與 Claude Code 會話默認用于訓練(除非 opt-out),允許訓練數據留存最長 5 年,彈窗默認"接受"+ 截止 2025-09-28 → 隱私爭議;企業/政府/教育/API(Bedrock/Vertex)不受影響。
運營/聲譽(非法律):2025-07 底 Pro/Max 周配額 + 5 小時計量收緊引社區反彈;模型"降智"主觀爭議;大模型"可主動結束極端辱罵對話"引討論。
監管:前沿大模型的 AI 安全/數據合規一般性壓力(行業共性);搜索無具體新執法動作 → 不展開臆測。
3. 核心專利布局
搜索零結果。 且 Anthropic 公開面以研究論文/安全披露(Constitutional AI、可解釋性)為主,非以專利組合著稱。我不給杜撰的專利數/號。 嚴謹結論需檢索 USPTO / Google Patents 受讓人 "Anthropic
PBC"——明確缺口,要的話我用工具去查。
4. 營收 & 估值 vs OpenAI(綜合本對話數據,標日期)
注:36kr 舊文里 OpenAI "$5000億 tender / 歷史 $400億輪"是更早時點,與 $8520億不沖突(不同輪次)。
可靠性總結:本次=中文二級財經媒體+抓取亂碼,關鍵數字打架、對"股權比例/專利"幾乎零覆蓋。方向(快速爬升、反超敘事)可信;任何精確比例/單點估值不可信。權威源應以 Anthropic 官方
newsroom、一手英文財經(Bloomberg/Reuters/FT/The Information)、法院 docket、USPTO 為準。
我可直接做:① extract 抓 Anthropic 官方公告 / 一手英文財經原文核對 "$300億@$9000億" ② 檢索 USPTO 專利受讓人 ③ 拉版權案 docket 現狀。要哪個?
提醒:搜索： 是網頁搜索,做這種結構化財務/法律/專利盡調先天不可靠;建議拆細 + 我用 extract 抓一手核對。
這條輸出最突出的一個點，是它在幫你判斷信息本身靠不靠譜。
查Anthropic盡調，搜回來的數據互相打架，$3800億、$9000億、$1.2萬億三個估值滿天飛。
它沒有挑一個最好看的數字糊弄你，而是按時間線排好、標上置信度，把$1.2萬億標成「單一離群值，不采信」，把 $9000億標成「條款階段，未官宣」，最后給你一個方向性結論。
股權比例查不到，它直接說「cap table未披露，我不編」；
專利搜索零結果，它也沒拿論文湊數。
對投資人來說，這比什么都重要。
盡調最怕的不是信息不夠，是信息看起來夠了但里面埋著錯的，你照著下了判斷。
這個輸出等于幫你做了第一輪信源清洗，哪些能用、哪些存疑、哪些是垃圾，分得明明白白，還告訴你下一步該去哪里補。
場景 4：安全工程師 — 威脅情報查詢
OpenClaw這類Agent擁有極高權限，想要讓它發揮強大能力，就不得不讓它控制計算機的海量數據。
安全問題也接踵而至，讓每一個想成為OPC的「超級個體」，都必須承擔起每個 IT 公司都要有的安全工程師的職責。
某天，你發現你的Agent后臺出現了一個陌生IP，你的直覺讓你緊張起來。
提示詞：
幫我查一下 103.171.86.220 這個 IP 是什么來頭。
輸出：
103.171.86.220 實查結論(權威源)
身份(APNIC whois)
網段:103.171.86.0/24,netname MSBSPL
持有者:Maba Safenet Broadband Services Private Limited(一家印度小型寬帶服務商)
國家:印度 IN(? 不是搜索暗示的印尼 INTRAKOM —— 那條是鄰近 /23 的無關記錄)
狀態:ASSIGNED PORTABLE,經 IRINN(印度國家級 NIR)
abuse 聯系人:airnetservicesjhs@gmail.com(用 Gmail 做 abuse 郵箱 —— 小運營商/管理粗放的信號,非惡意證據)
BGP 路由起源(Team Cymru)
AS140129 — MSBSPL-AS-IN,同一家公司;前綴 103.171.86.0/24,APNIC 分配 2021-08-09
登記者 = 宣告者(都是 MSBSPL/AS140129),沒有"掛別人名下、第三方 announce"的錯配 → 這塊地址確由這家印度小寬帶商自宣告自用
反向 DNS
PTR = cache6607.totousb.com.
cacheNNNN 是典型緩存/代理/CDN 節點命名;totousb.com 走 GoDaddy,創建 2023-04-02(~3 年,不算新),NS 為 domaincontrol.com,2026-05-14 剛更新過 —— 域名不新,但屬不知名域名
研判(基于事實的中性推斷,非定性)
"印度小型寬帶 ISP 的 PORTABLE /24 + PTR 是 cache*.某不知名域名" 這種畫像,在威脅狩獵里最常對應:住宅代理 / proxyware 出口節點、廉價被濫用主機、或掃描來源;但也可能就是個合法的小緩存/CDN
或普通寬帶客戶。不能據此判惡意。
關鍵看方向:
出站(你的資產主動連它):需要警惕 —— 業務上為什么要連一個印度小 ISP 的"cache"節點?像可疑外連/代理回連。
入站(它連你):更像掃描或代理流量來源。
誠實邊界:whois/ASN 只回答"登記和宣告者是誰",不代表當前實際使用者,更不代表善惡。我沒有信譽數據(AbuseIPDB / GreyNoise / VirusTotal / URLhaus / Shodan / Talos / 被動 DNS),不編造定性。
我可直接幫你做(選一個)
1. 用 AnySearch security/extract 抓 AbuseIPDB / GreyNoise / URLhaus / Shodan 上該 IP 的公開記錄(標來源、不替你下結論)。
2. 查同 /24 其它 PTR —— 若整段都是 *.totousb.com 的 cache 節點,則更像一個代理/CDN 池,定性參考價值大。
3. 給你本地取證模板:從這條連接倒查進程/方向/頻率/端口、是否周期 beacon(lsof -i、Zeek/Suricata、PCAP 看 SNI/JA3)。
提醒:搜索： 觸發的是網頁搜索,對 IP/IOC 只會返回亂碼鄰段垃圾(這次就是);IP 溯源直接用 whois/dig/Cymru 或對接你們 TIP 更靠譜。要我接著查哪個?
這條輸出最值得注意的一個點，前兩個場景都沒體現過，就是它足夠誠實。
查一個IP，它沒有硬編一個「惡意評分8.5 / 10」糊弄你。
它把 whois、BGP、反向 DNS 三層信息老老實實擺出來，告訴你這是一家印度小寬帶商的地址段，PTR 指向一個不知名的 cache 節點，畫像上像代理出口或掃描源，但也可能就是個正常的緩存服務。
然后明確說了一句，「我沒有信譽數據，不編造定性」。
對安全工程師來說，這比瞎給結論重要一百倍。
凌晨兩點你看到一個告警，最怕的不是「查不到」，而是工具信心滿滿給你一個錯的判斷，你照著執行了。
這個輸出把已知事實和未知邊界分得很清楚，還糾正了搜索結果里把印度 IP 誤標成印尼的錯誤，最后給了三個可以立刻執行的下一步。
這是 AnySearch 在前兩個場景之外展現的另一種能力，不是「什么都能查到」，而是「查到的東西靠譜，查不到的不瞎編」。
對專業場景來說，這個比信息量更關鍵。
四個場景看下來，AnySearch 展現的不是同一個優點的重復，而是四層不同的能力：
場景1是聚合廣度，場景2是專業深度，場景3是對已知的甄別，場景4是對未知的誠實。
這四個加在一起，才是「為Agent而生」真正的意思。
不是「搜索引擎」，專為Agent而生
AnySearch的核心能力，可以用一句話概括——
一個統一入口，接入海量專業數據源，讓AI Agent高效連接真實世界信息。
但「統一入口」四個字的分量，只有真正做過Agent開發的人才能體會。
在AnySearch出現之前，如果想讓Agent同時具備金融查詢、代碼搜索、安全情報、企業工商和學術文獻的檢索能力，就需要：
分別注冊企查查、Finnhub、PubMed、VirusTotal的賬號，學習幾十套不同的API文檔，管理幾十個API Key的限流和余額，還得自己寫一層路由邏輯來決定什么查詢發給哪個數據源。
這套活兒干下來，「搜索模塊」的開發成本可能比Agent本身還高。
AnySearch把這一切打包了。一個API Key，訪問AI所需的優質數據源。
開發者不用再當「API集成工程師」，只需要把AnySearch接進去，剩下的交給它。
一個API，通吃「優質」數據源
只需要發出查詢，AnySearch自動路由到最合適的數據源，返回結構化的Markdown結果。
對Agent來說，背后接了多少個數據源、每個源的認證方式是什么、結果格式有什么差異，這些復雜性全部被AnySearch吃掉了。
而且它覆蓋的「場景廣度」，遠超大多數開發者的預期——
查企業股權穿透、獲取A股分鐘級行情、檢索法院裁決書全文、搜索GitHub生產級代碼實現，甚至提交文件到VirusTotal做惡意檢測，一個API即可搞定。
可見，AnySearch覆蓋的是Agent的全場景需求，而不只是某個垂直領域。
這些信息占互聯網總量的80%以上，卻是Google和Exa完全觸及不到的。
這不是它們「還沒索引到」的問題，而是架構上就不可能覆蓋的盲區。
不僅如此，AnySearch的接入方式足夠靈活：
REST API（通用，適配任何編程語言和Agent框架）、MCP Server（Claude Desktop、Cursor、Windsurf、OpenCode配置一行JSON即可接入）、Skill（直接作為Agent技能調用）。
三種方式，覆蓋從硬核開發者到輕度極客的全部需求。
這聽起來像是一個「聚合」的故事，但AnySearch做的遠不止數據源打包。
它在底層構建了一套完整的智能路由和結果融合機制，讓Agent從「搜到信息」直接跨越到「搜到能用的信息」。
殺手锏：智能意圖路由
AnySearch的技術內核里，藏著一個關鍵模塊：智能意圖路由（Intent Classifier）。
當一條查詢進入AnySearch，系統內置的Intent Classifier會自動識別查詢意圖，通過多維路由匹配，精準路由到最相關的2-3個數據源。
這意味著系統不會對所有數據源做全量扇出，只查最該查的源，速度更快，Token消耗更低。
當多個數據源同時返回結果時，AnySearch通過RRF（Reciprocal Rank Fusion）算法進行結果融合。
同一條信息被多個源交叉驗證時排名自動提升，URL規范化去重避免重復。
融合后再經過多維度質量重排序，Agent可以直接用分數做決策，不用再花Token去做二次篩選。
而在輸出格式上，AnySearch返回的是清洗后的結構化Markdown，通常每條結果500-2000Token。
同樣的查詢，Agent用Exa搜10條結果，平均消耗約15,000 Token；用AnySearch搜5條高質量結果，平均消耗約5,000 Token。
顯而易見，Token消耗降低60%-70%！
用更少的Token拿到更準的信息，這對跑在生產環境中的Agent來說，意味著實實在在的成本節省和效率提升。
隱私這件事，做到了架構級
在AI搜索領域，隱私不是一個「加分項」，而是一個底線。
你的Agent通過搜索接口查詢的內容，可能涉及商業機密（競品調研）、安全敏感信息（IP威脅排查）、法律風險數據（公司盡調）。
如果這些查詢內容被記錄、被分析、被用于訓練模型——后果不堪設想。
AnySearch的做法是：從架構層面將隱私保護作為第一優先級。
具體來說：用戶的搜索查詢不會被記錄，不會被用于訓練模型，不會被分享給第三方。
系統不收集任何遙測數據，不追蹤用戶行為，不做用戶畫像。
所有API請求通過加密通道傳輸，查詢內容在處理完成后即時丟棄，不做持久化存儲。
一句話總結：匿名使用、無追蹤、零遙測——你的查詢只屬于你。
這在當前AI搜索賽道中是非常稀缺的。大多數AI搜索工具，或多或少都在利用用戶查詢數據來優化自身模型——這是一個公開的秘密。
AnySearch選擇不碰這條線，對于處理敏感信息的開發者和企業用戶來說，這一點尤為關鍵。
搜索，AI時代被低估的基礎設施
回望搜索引擎的歷史，每一次范式轉移，都伴隨著「誰在搜」的改變。
1998年Google誕生時，搜索是幫人找網頁。2010年代移動互聯網興起時，搜索變成了幫人找服務。
2023年ChatGPT引爆LLM浪潮后，Perplexity們把搜索變成了幫人找答案。
而現在，2026年，搜索正在經歷第四次范式轉移：從幫人找信息，到幫AI理解世界。
AnySearch團隊在一封寫給開發者的公開信中說了這樣一段話——
我們始終相信，未來的AI不只要「會思考」，更需要真正看見世界、理解世界。
互聯網時代的搜索引擎幫助人類尋找網頁；而在AI時代，Agent需要的不是一串鏈接，而是可信、結構化、可執行的信息結果。
這段話點出了一個很多人還沒意識到的事實：當Agent開始執行復雜任務時，真正的瓶頸往往不再是推理能力，而是信息獲取能力。
缺少可靠的信息獲取層，再強大的AI模型，也難以真正理解現實世界。
這就是AnySearch的定位：一家應用型AI實驗室，正在構建AI時代的全新搜索基礎設施。
現在回看，AnySearch做的事情，本質上是在AI時代重新定義「搜索」這件事。
過去的搜索是給人看的：返回一堆鏈接，人自己去點擊、閱讀、篩選、總結。
但在Agent時代，搜索的消費者變了，變成了機器。
機器不需要鏈接，不需要HTML，不需要花花綠綠的搜索結果頁，需要的是結構化的、經過驗證的、可以直接用于推理和決策的數據。
這是一個全新的基礎設施層。誰先把這一層做好，誰就拿到了AI Agent生態的入場券。
AnySearch跑在了前面。
它能跑多遠？如今，海外開發者已經給出了第一輪答案。
彩蛋
今天起，AnySearch面向所有開發者免費使用，可接入任意Agent體驗——
GitHub：https://github.com/anysearch-ai
也可在ClawHub、SkillHub、Glama、skills.sh等插件商店直接獲取
為偉大思想而生！
AI+時代，互聯網思想（wanging0123)，
第一必讀自媒體
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
