feat: add DeepSeek agent layer with job filter and chat automation

[Richard13310]

Adds agent/ orchestrator, tools/ filter layer, agent CLI commands, local docs, run.py entry, and tests. Extends AIService for OpenAI-compatible tool calling.

关联 Issue / Related Issue

Closes #

变更说明 / Summary

变更类型 / Type

• feat: 新功能
• fix: Bug 修复
• refactor: 重构（不改变外部行为）
• perf: 性能优化
• docs: 文档
• test: 测试
• chore: 构建/依赖/配置
• ci: CI 工作流

Breaking Change

• 本 PR 不包含 破坏性变更
• 本 PR 包含 破坏性变更（请在下方说明迁移路径）

截图 / Screenshot

测试 / Test Plan

• uv run pytest tests/ -q 全部通过
• uv run ruff check src/ tests/ 无报错
• uv run mypy src/boss_agent_cli 无报错
• uv run boss --help 可加载
• uv run boss schema --format native 返回合法 JSON 信封
• 新增/修改的功能已有对应测试覆盖
• 本地跑过涉及命令（如有可粘贴已脱敏输出）

文档与契约 / Docs & Contracts

• 如新增命令：已更新 src/boss_agent_cli/commands/schema.py
• 如变更 CLI 行为：已更新 README.md 和 docs/capability-matrix.md
• 如新增 MCP 工具：已更新 mcp-server/server.py 和 mcp-server/README.md
• 如新增错误码：已添加到 schema.py 的 error_codes
• 已更新 CHANGELOG.md 的 [Unreleased] 段落
• 如变更 Agent 主卖点或安装路径：已同步更新 README / landing 的 MCP 接入说明、PyPI 版本与 GitHub Release 说明

安全与规范 / Safety & Convention

• commit message 格式: type: 中文描述
• 无 Co-authored-by 尾注或 AI 署名行
• 无敏感信息（Token / 密码 / Cookie / security_id / 手机号 / 微信 / 真实账号）
• 如涉及 Cookie、CDP、patchright、请求频率或真实账号，已阅读 docs/platform-risk.md
• 如涉及发布流程，已阅读 docs/maintainer/release-checklist.md
• 无新增外部 CDN / script 依赖（HTML 报表类特别注意）

[can4hou6joeng4]

Thanks for the contribution. I cannot approve this PR in its current shape because it crosses several project boundaries that are deliberately strict for this repository.

Required revision before this can move forward:

1. Scope this PR down to low-risk, read-only local assistance.

   • Remove or keep fully blocked: send_message, exchange_contact, greet_recruiter, apply_job, mark_contact, bulk chat/contact processing, and any path that reads or writes recruiter/candidate chat state as an automated workflow.
   • The project default is Low-Risk Assistance Mode: local assistance, read-only first, user-triggered, no automatic outreach, no bulk contact, and no risk-control bypass.
   • Sensitive actions must end in Official Platform Handoff, not CLI/browser automation.

2. Remove risk-control / high-risk automation language and implementation.

   • The added docs/code mention CDP/browser behavior for high-risk actions and wording such as making operations look more human / avoiding platform risk controls.
   • That is not an acceptable direction here. Do not add CDP, patchright, or browser-channel retries for actions that are compliance-blocked.

3. Keep only a narrow, reviewable slice.

   • AIService.chat_completion may be acceptable if it is independently useful, OpenAI-compatible, typed, tested, and not coupled to chat/contact automation.
   • Local-only AI analysis helpers may be acceptable if they operate on user-provided/local data and are wired through the existing CLI/schema patterns.
   • Please split unrelated large docs/framework files out unless they are necessary for that narrow slice.

4. Clean up repository integration.

   • Remove _COMMENTED.py snapshot files.
   • Remove requirements.txt and run.py unless there is a strong reason they cannot use the existing pyproject.toml package entry point.
   • Any new CLI command must update src/boss_agent_cli/commands/schema.py and preserve the JSON envelope contract: stdout JSON only, stderr logs/progress only, ok/exit-code consistency, and structured errors.

5. Fix commit metadata and PR template evidence.

   • The commit includes Co-authored-by: Cursor <cursoragent@cursor.com>, which conflicts with this repo's commit-message/source-identifier rules.
   • Please rewrite the commit message/history for this branch so it follows type: 中文描述 and has no tool/model/agent attribution lines.
   • Complete the PR template checkboxes and provide a real test plan.

6. Restore full verification.

   • The current check rollup only shows GitGuardian. Before review can continue, this PR needs the normal required checks visible and passing: CI, Docs, CodeQL, Python test matrix, lint, typecheck, and P0 quality baseline.

A path that is likely reviewable: a much smaller PR that only adds a tested OpenAI-compatible tool-calling helper and/or local read-only job analysis, with no chat/contact write operations, no bulk workflow, no platform-risk-control language, and complete schema/docs/tests for any exposed CLI behavior.

[can4hou6joeng4]

Thanks for the contribution. There's a reusable piece here (AIService.chat_completion() for OpenAI-compatible tool-calling appends cleanly), but this needs a structural rework, not a rebase:

1. Command-name collision (blocking). agent is already owned by the released automation engine (commands/agent.py: run/train/review/pending/stats/control/stop). Registering a different group under the same name silently overrides one or the other and would break tests/test_agent_automation* + schema availability. Please rename (e.g. fold into boss ai) and resolve the register.py conflict (note feat: 新增受限 Research Mode 的可恢复 DrissionPage 批量采集工作流 #339 also edits register.py).

2. Ungoverned sensitive surface (blocking). The new subcommands write to the platform (platform.friend_label) and send candidate chat content to cloud DeepSeek, but call require_compliance_allowed zero times, aren't in compliance._POLICY_DEFINITIONS, and aren't in SCHEMA_DATA — bypassing the assisted/research gate and invisible to boss schema. Per ADR-0002, every write/personal-data command must register in the capability registry, gate to research mode, and appear in schema. agent chat-run --auto-mark (default true) is the sharpest case: it iterates the whole conversation list, sends each to the cloud, and writes a 不合适 label — all ungated.

3. Cloud reply path bypasses the local-only guardrail in automation/reply_ai.py. Route through the local provider, or explicitly bound it under research mode (redaction, bounded runs, stop).

4. Repo hygiene (before review): delete the 3 *_COMMENTED.py duplicates under src/; the 5 root .md files (they hardcode file:///d:/download/py_test/... local paths); root run.py and requirements.txt. Fix indentation to tabs in tools/chat_tools.py, tools/filter_tools.py, tools/job_tools.py, run.py (repo is indent-style=tab; ruff format --check fails). agent config --api-key silently clobbers the shared AIConfigStore used by boss ai config, and hardcodes the DeepSeek base_url instead of using ai/config.PROVIDER_BASE_URLS (which already has deepseek).

5. Dedup decision: this is a third parallel job-filter + automation stack (tools/filter_tools.py reimplements search_filters; agent/ reimplements automation/) alongside the existing engine and feat: 新增受限 Research Mode 的可恢复 DrissionPage 批量采集工作流 #339. Worth converging on one direction before investing more. Happy to help scope the governance integration once the rename + convergence direction are decided.

[can4hou6joeng4]

Thanks again for this work. After the 1.16.0 governance baseline landed, I want to be direct about where this PR stands so your time isn't wasted.

As-is it can't merge — it's a third parallel automation stack (alongside the existing boss agent engine and #339's crawl workflow), it takes the already-owned agent command name, and it sits entirely outside the compliance capability-policy registry (ungated platform writes + cloud chat processing). Details are in my earlier review above. Two paths:

• Rework — rename off agent (or fold into boss ai); bring every write/personal-data subcommand under compliance._POLICY_DEFINITIONS + require_compliance_allowed gated to research mode; register in SCHEMA_DATA; reconcile the cloud reply path with automation/reply_ai.py's local-only rule; delete the pollution (3 *_COMMENTED.py, 5 root .md with local paths, run.py, requirements.txt); fix tabs. The one clearly-reusable piece — AIService.chat_completion() — would be very welcome as a small standalone PR on its own.

• Close as superseded — totally fine too; feat: 新增受限 Research Mode 的可恢复 DrissionPage 批量采集工作流 #339 already covers the DrissionPage/automation direction under governance, and a DeepSeek provider can come separately via ai/config.PROVIDER_BASE_URLS.

Could you let us know which you'd prefer in the next week or so? Otherwise I'll close it as superseded by #339 (with thanks) to keep the queue clear — reopening is always welcome.