mirror of
https://git.openapi.site/https://github.com/desirecore/market.git
synced 2026-09-05 21:23:57 +08:00
feat: 发布通用人效与资源优化能力
增加跨行业的人效与资源优化需求澄清、模型求解与独立验收能力，并固化公共市场的信息边界与发布前检查。
This commit is contained in:
55
AGENTS.md
Normal file
55
AGENTS.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# AGENTS.md
|
||||
|
||||
This repository is a public marketplace. Every contribution must be reusable,
|
||||
customer-neutral, and safe to index publicly.
|
||||
|
||||
## Public information boundary
|
||||
|
||||
- Never put a tenant, customer, prospect, partner, or other confidential identity
|
||||
in tracked files, paths, filenames, Agent or Skill IDs, frontmatter, descriptions,
|
||||
examples, fixtures, memories, generated artifacts, or screenshots.
|
||||
- Apply the same rule to Git metadata and collaboration text: branch names, commit
|
||||
subjects and bodies, PR or issue titles and bodies, comments, and review replies.
|
||||
- Describe reusable capabilities with domain-neutral roles and entities. Put
|
||||
customer-specific prompts, facts, mappings, examples, data, and deployment
|
||||
settings only in private AgentFS homes, private repositories, or private runtime
|
||||
configuration.
|
||||
- Do not add a real confidential token to a denylist, test fixture, documentation,
|
||||
or example. A literal denylist in a public repository creates a second leak.
|
||||
|
||||
## Required pre-publication check
|
||||
|
||||
Before committing or opening/updating a PR:
|
||||
|
||||
1. Obtain the sensitive tokens through a private channel and keep them outside the
|
||||
repository.
|
||||
2. Scan the complete working tree, including hidden files while excluding `.git`.
|
||||
3. Scan new path names, branch names, commit subjects and bodies, and the proposed
|
||||
PR/issue/review text.
|
||||
4. Review examples semantically: changing a proper noun is insufficient when an
|
||||
example still exposes a customer-specific organization shape or private fact.
|
||||
5. Run the repository validation and translation-freshness checks documented in
|
||||
`README.md`.
|
||||
|
||||
A zero-result scan is a release requirement. Record only that the check passed;
|
||||
never persist the confidential search tokens or command history in the repository.
|
||||
|
||||
## Incident response
|
||||
|
||||
If confidential identity or data reaches the public repository:
|
||||
|
||||
1. Stop the merge or release and neutralize all editable GitHub metadata.
|
||||
2. Replace the public content with a genuinely reusable abstraction; do not merely
|
||||
rename the customer.
|
||||
3. If reachable Git history is affected, make a mirror backup, rewrite only the
|
||||
affected history, verify expected tree objects, push with an exact lease, and
|
||||
restore branch protections immediately.
|
||||
4. Treat pull-request refs, cached views, reviews, notifications, and search-engine
|
||||
caches as separate surfaces. Follow the hosting provider's sensitive-data
|
||||
removal process instead of claiming that a force-push removed them.
|
||||
5. Re-run all publication checks before reopening or merging work.
|
||||
|
||||
## Instruction synchronization
|
||||
|
||||
`AGENTS.md` and `CLAUDE.md` are equivalent repository policy entrypoints. Any
|
||||
substantive change to one must be made to the other in the same commit.
|
||||
55
CLAUDE.md
Normal file
55
CLAUDE.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This repository is a public marketplace. Every contribution must be reusable,
|
||||
customer-neutral, and safe to index publicly.
|
||||
|
||||
## Public information boundary
|
||||
|
||||
- Never put a tenant, customer, prospect, partner, or other confidential identity
|
||||
in tracked files, paths, filenames, Agent or Skill IDs, frontmatter, descriptions,
|
||||
examples, fixtures, memories, generated artifacts, or screenshots.
|
||||
- Apply the same rule to Git metadata and collaboration text: branch names, commit
|
||||
subjects and bodies, PR or issue titles and bodies, comments, and review replies.
|
||||
- Describe reusable capabilities with domain-neutral roles and entities. Put
|
||||
customer-specific prompts, facts, mappings, examples, data, and deployment
|
||||
settings only in private AgentFS homes, private repositories, or private runtime
|
||||
configuration.
|
||||
- Do not add a real confidential token to a denylist, test fixture, documentation,
|
||||
or example. A literal denylist in a public repository creates a second leak.
|
||||
|
||||
## Required pre-publication check
|
||||
|
||||
Before committing or opening/updating a PR:
|
||||
|
||||
1. Obtain the sensitive tokens through a private channel and keep them outside the
|
||||
repository.
|
||||
2. Scan the complete working tree, including hidden files while excluding `.git`.
|
||||
3. Scan new path names, branch names, commit subjects and bodies, and the proposed
|
||||
PR/issue/review text.
|
||||
4. Review examples semantically: changing a proper noun is insufficient when an
|
||||
example still exposes a customer-specific organization shape or private fact.
|
||||
5. Run the repository validation and translation-freshness checks documented in
|
||||
`README.md`.
|
||||
|
||||
A zero-result scan is a release requirement. Record only that the check passed;
|
||||
never persist the confidential search tokens or command history in the repository.
|
||||
|
||||
## Incident response
|
||||
|
||||
If confidential identity or data reaches the public repository:
|
||||
|
||||
1. Stop the merge or release and neutralize all editable GitHub metadata.
|
||||
2. Replace the public content with a genuinely reusable abstraction; do not merely
|
||||
rename the customer.
|
||||
3. If reachable Git history is affected, make a mirror backup, rewrite only the
|
||||
affected history, verify expected tree objects, push with an exact lease, and
|
||||
restore branch protections immediately.
|
||||
4. Treat pull-request refs, cached views, reviews, notifications, and search-engine
|
||||
caches as separate surfaces. Follow the hosting provider's sensitive-data
|
||||
removal process instead of claiming that a force-push removed them.
|
||||
5. Re-run all publication checks before reopening or merging work.
|
||||
|
||||
## Instruction synchronization
|
||||
|
||||
`AGENTS.md` and `CLAUDE.md` are equivalent repository policy entrypoints. Any
|
||||
substantive change to one must be made to the other in the same commit.
|
||||
11
README.md
11
README.md
@@ -23,9 +23,9 @@ DesireCore 官方市场仓库，存放官方维护的 Agent/Skill 定义，以
|
||||
The market currently contains:
|
||||
|
||||
- `1` Agent: `desirecore`
|
||||
- `31` local built-in skills with `SKILL.md`
|
||||
- `32` local built-in skills with `SKILL.md`
|
||||
- `25` external skill entries with `entry.json`
|
||||
- `56` publishable skills in total (`SKILL.md` + `entry.json`)
|
||||
- `57` publishable skills in total (`SKILL.md` + `entry.json`)
|
||||
|
||||
## Skill Sources
|
||||
|
||||
@@ -37,10 +37,15 @@ dev-environment-setup, discover-agent, docx, frontend-design, guizang-ppt,
|
||||
image-to-image, mail-operations, manage-skills, manage-teams, markdown,
|
||||
minimax-music-gen, minimax-video-gen, nodejs-runtime, pdf, pptx,
|
||||
python-runtime, registering-services, s3-storage-operations, skill-creator,
|
||||
tech-diagram, update-agent, using-services, web-access, workflow,
|
||||
tech-diagram, update-agent, using-services, web-access, workflow, workforce-optimization,
|
||||
xiaomi-tts, xlsx
|
||||
```
|
||||
|
||||
`builtin-skills.json#retired` lists old built-in Skill IDs that clients may safely retire during
|
||||
startup. Clients only remove copies tracked in `skills.lock` as market/bundled content whose
|
||||
`SKILL.md` hash still matches the installed record; manually installed or locally modified copies
|
||||
are preserved. An ID must not appear in both `skills` and `retired`.
|
||||
|
||||
External entries are marketplace pointers to Git/Web/ZIP sources:
|
||||
|
||||
```text
|
||||
|
||||
@@ -29,7 +29,9 @@
|
||||
"using-services",
|
||||
"web-access",
|
||||
"workflow",
|
||||
"workforce-optimization",
|
||||
"xiaomi-tts",
|
||||
"xlsx"
|
||||
]
|
||||
],
|
||||
"retired": []
|
||||
}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "DesireCore Official Market",
|
||||
"version": "1.2.21",
|
||||
"version": "1.2.23",
|
||||
"schemaVersion": "1.1.0",
|
||||
"supportedLocales": ["zh-CN", "en-US"],
|
||||
"defaultLocale": "en-US",
|
||||
@@ -27,7 +27,7 @@
|
||||
},
|
||||
"stats": {
|
||||
"totalAgents": 1,
|
||||
"totalSkills": 56,
|
||||
"totalSkills": 57,
|
||||
"lastUpdated": "2026-08-07"
|
||||
},
|
||||
"features": [
|
||||
|
||||
@@ -48,5 +48,41 @@ class ModelInvocationPolicyTests(unittest.TestCase):
|
||||
self.assertEqual("model-invocation-policy", issues[0].rule)
|
||||
|
||||
|
||||
class BuiltinSkillManifestTests(unittest.TestCase):
|
||||
def validate(self, payload: dict[str, object], skills: list[str]) -> list[object]:
|
||||
report = VALIDATOR.Report()
|
||||
VALIDATOR.validate_builtin_manifest(report, payload, skills)
|
||||
return report.issues
|
||||
|
||||
def test_allows_disjoint_sorted_retired_ids(self) -> None:
|
||||
self.assertEqual([], self.validate(
|
||||
{"skills": ["new-skill"], "retired": ["old-skill"]},
|
||||
["new-skill"],
|
||||
))
|
||||
|
||||
def test_rejects_active_retired_overlap(self) -> None:
|
||||
issues = self.validate(
|
||||
{"skills": ["same-skill"], "retired": ["same-skill"]},
|
||||
["same-skill"],
|
||||
)
|
||||
self.assertTrue(any("overlap" in issue.message for issue in issues))
|
||||
|
||||
def test_rejects_unknown_fields_and_invalid_ids(self) -> None:
|
||||
issues = self.validate(
|
||||
{"skills": ["Invalid_ID"], "retired": [], "unknown": True},
|
||||
["Invalid_ID"],
|
||||
)
|
||||
self.assertTrue(any("unknown top-level" in issue.message for issue in issues))
|
||||
self.assertTrue(any("invalid Skill IDs" in issue.message for issue in issues))
|
||||
|
||||
def test_reports_unsorted_active_skills_once(self) -> None:
|
||||
issues = self.validate(
|
||||
{"skills": ["second-skill", "first-skill"], "retired": []},
|
||||
["first-skill", "second-skill"],
|
||||
)
|
||||
sort_issues = [issue for issue in issues if "not sorted" in issue.message]
|
||||
self.assertEqual(1, len(sort_issues))
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
unittest.main()
|
||||
|
||||
@@ -351,11 +351,61 @@ def count_publishable_skills() -> tuple[list[str], list[str]]:
|
||||
def validate_builtin_skills(report: Report, skill_md_names: list[str]) -> None:
|
||||
builtin_path = REPO_ROOT / "builtin-skills.json"
|
||||
builtin = load_json(builtin_path, report, "builtin-skills")
|
||||
validate_builtin_manifest(report, builtin, skill_md_names)
|
||||
|
||||
|
||||
def validate_builtin_manifest(
|
||||
report: Report,
|
||||
builtin: dict[str, Any],
|
||||
skill_md_names: list[str],
|
||||
) -> None:
|
||||
unknown = sorted(set(builtin) - {"skills", "retired"})
|
||||
if unknown:
|
||||
report.add(Issue(
|
||||
"builtin-skills.json",
|
||||
"builtin-skills",
|
||||
f"unknown top-level fields {unknown}",
|
||||
))
|
||||
|
||||
skills = builtin.get("skills")
|
||||
if not isinstance(skills, list) or not all(isinstance(x, str) for x in skills):
|
||||
report.add(Issue("builtin-skills.json", "builtin-skills", "skills must be a list of strings"))
|
||||
return
|
||||
|
||||
retired = builtin.get("retired", [])
|
||||
if not isinstance(retired, list) or not all(isinstance(x, str) for x in retired):
|
||||
report.add(Issue("builtin-skills.json", "builtin-skills", "retired must be a list of strings"))
|
||||
return
|
||||
|
||||
for field, values in (("skills", skills), ("retired", retired)):
|
||||
invalid = sorted({value for value in values if not NAME_PATTERN.fullmatch(value)})
|
||||
if invalid:
|
||||
report.add(Issue(
|
||||
"builtin-skills.json",
|
||||
"builtin-skills",
|
||||
f"{field} contains invalid Skill IDs {invalid}",
|
||||
))
|
||||
if len(values) != len(set(values)):
|
||||
report.add(Issue(
|
||||
"builtin-skills.json",
|
||||
"builtin-skills",
|
||||
f"{field} contains duplicate Skill IDs",
|
||||
))
|
||||
if field == "retired" and values != sorted(values):
|
||||
report.add(Issue(
|
||||
"builtin-skills.json",
|
||||
"builtin-skills",
|
||||
f"{field} list is not sorted",
|
||||
))
|
||||
|
||||
overlap = sorted(set(skills) & set(retired))
|
||||
if overlap:
|
||||
report.add(Issue(
|
||||
"builtin-skills.json",
|
||||
"builtin-skills",
|
||||
f"active and retired Skill IDs overlap {overlap}",
|
||||
))
|
||||
|
||||
expected = sorted(skill_md_names)
|
||||
actual = list(skills)
|
||||
if actual != expected:
|
||||
|
||||
99
skills/workforce-optimization/SKILL.md
Normal file
99
skills/workforce-optimization/SKILL.md
Normal file
@@ -0,0 +1,99 @@
|
||||
---
|
||||
name: workforce-optimization
|
||||
description: >-
|
||||
Structure, predict, compile, solve, independently validate, and recover workforce-efficiency optimization through versioned multi-agent artifacts and a governed solver connector. Use for service-coverage design, hierarchical resource allocation, performance targets, centralized task scheduling, staffing, shifts, or general LP/MILP. 用户提到人效、服务范围、资源划分、绩效目标、任务调度、排班、运筹优化或 LP/MILP 时使用。
|
||||
version: 2.3.2
|
||||
type: procedural
|
||||
risk_level: medium
|
||||
status: enabled
|
||||
disable-model-invocation: true
|
||||
tags:
|
||||
- workforce-optimization
|
||||
- operations-research
|
||||
- mindopt
|
||||
- multi-agent
|
||||
provides:
|
||||
tools:
|
||||
- TeamArtifact
|
||||
- OptimizationPredict
|
||||
- OptimizationCompile
|
||||
- MindOptSolve
|
||||
- OptimizationValidate
|
||||
requires:
|
||||
connections:
|
||||
- solver.mindopt.endpoint
|
||||
- solver.mindopt.server-name
|
||||
- solver.mindopt.token
|
||||
- solver.mindopt.ca
|
||||
- solver.mindopt.client-cert
|
||||
- solver.mindopt.client-key
|
||||
metadata:
|
||||
author: workforce-optimization-team
|
||||
updated_at: '2026-08-07'
|
||||
i18n:
|
||||
default_locale: en-US
|
||||
source_locale: zh-CN
|
||||
locales:
|
||||
- zh-CN
|
||||
- en-US
|
||||
zh-CN:
|
||||
name: 人效与资源优化
|
||||
short_desc: 用版本化多智能体流水线梳理、预测、求解并独立验收人效优化
|
||||
description: >-
|
||||
将服务范围、分层资源分配、绩效目标、集中任务调度、人员配置、排班和通用 LP/MILP 需求转成可恢复的场景、预测、模型、求解与独立验收制品。
|
||||
body: ./SKILL.zh-CN.md
|
||||
source_hash: sha256:0157b807fc76aeb8
|
||||
translated_by: human
|
||||
en-US:
|
||||
name: Workforce and Resource Optimization
|
||||
short_desc: Structure, solve, and independently validate workforce optimization with versioned multi-agent artifacts
|
||||
description: >-
|
||||
Turn requests for service coverage, hierarchical resource allocation, performance targets, centralized task scheduling, staffing, shift planning, and general LP/MILP into recoverable scenario, prediction, model, solution, and independent-validation artifacts.
|
||||
body: ./SKILL.md
|
||||
source_hash: sha256:0157b807fc76aeb8
|
||||
translated_by: human
|
||||
market:
|
||||
icon: >-
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none"><defs><linearGradient id="bwo-a" x1="3" y1="3" x2="21" y2="21" gradientUnits="userSpaceOnUse"><stop stop-color="#34C759"/><stop offset="1" stop-color="#007AFF"/></linearGradient></defs><path d="M5 17.5V11m7 6.5V6m7 11.5V9" stroke="url(#bwo-a)" stroke-width="2" stroke-linecap="round"/><path d="M3.5 20.5h17" stroke="#34C759" stroke-width="1.5" stroke-linecap="round"/><circle cx="5" cy="8" r="2" fill="#34C759"/><circle cx="12" cy="3.5" r="2" fill="#007AFF"/><circle cx="19" cy="6.5" r="2" fill="#AF52DE"/></svg>
|
||||
category: business
|
||||
maintainer:
|
||||
name: 人效与资源优化项目组
|
||||
verified: true
|
||||
compatible_agents: []
|
||||
channel: latest
|
||||
required_client_version: 10.0.99
|
||||
---
|
||||
|
||||
# Workforce and Resource Optimization
|
||||
|
||||
## L0
|
||||
|
||||
Turn natural-language workforce-efficiency requests into reviewable and recoverable artifacts, execute approved LP/MILP only through the governed MindOpt connector, and independently recompute every result before delivery.
|
||||
|
||||
## L1
|
||||
|
||||
- Before routing or modeling, the natural-language entry Agent must read the [requirement-clarification framework](references/requirement-clarification-framework.md) in full and follow its real-decision, mandatory-question, and conditional-question branches.
|
||||
- First read the AgentFS user profile, preferences, and relationship memories already injected into the current context. Choose professional, business-guided, or evidence-insufficient adaptive language only from user-confirmed, current, non-conflicting evidence about expertise or communication preference. Employer, job title, one use of jargon, or model inference is not sufficient evidence.
|
||||
- Professional language may expose the complete structured information contract at once and accept a batch answer. Business-guided language uses plain-language groups in impact order for as many turns as needed. When evidence is insufficient, show a neutral coverage outline and ask the user's preference. Every mode maintains the same complete question map; never omit a model-changing item merely to reduce turns, question count, or cognitive load.
|
||||
- End every first response with the two-sentence fixed fact-gate footer defined by the requirement-clarification framework. Do not paraphrase, shorten, merge, or omit either sentence.
|
||||
- Maintain a fact ledger with `fact_state`, `value`, `source`, and `model_impact`. Only confirmed user facts, confirmed data, deterministic rules, or confirmed non-applicability may enter a model.
|
||||
- Treat relative business-time expressions such as today, tomorrow, the next N days, or this quarter as `pending_confirmation` until the current request confirms the business timezone, business calendar, date-time anchor, and applicable day-boundary, cutoff, holiday, and overnight rules. A system clock or host timezone is environment evidence, not a business rule.
|
||||
- Isolate every new request from historical contamination. Facts from another conversation, Plan, artifact, memory, or sample remain `pending_confirmation` until the user explicitly carries them into the current request; do not search for or reuse a semantically similar Plan as evidence for the first response.
|
||||
- Use one entry Agent for routing, consolidated questions, and final delivery. Assign one owner to each stage.
|
||||
- For the full path, publish `SceneSpec`, `DataContract`, `PredictionArtifact`, `OptimizationSpec`, `SolveResult`, `ValidationReport`, and `DeliveryBundle` in dependency order through `TeamArtifact`.
|
||||
- When training data exists, call `OptimizationPredict`; use ordered holdout, train-only imputation, tuning, metrics, baseline comparison, and explicit fallback rules.
|
||||
- Compile general models with `OptimizationCompile`, solve once with `MindOptSolve`, and retain status, variables, objective, request/job IDs, HTTPS transport, solver evidence, and IIS when infeasible.
|
||||
- Require the validation owner to call `OptimizationValidate` and recompute variable domains, hard constraints, objective, baseline delta, and IIS traceability from raw values.
|
||||
- Treat every settled successful Tool call as authoritative. After an interruption, synthesize the persisted result without repeating the Tool.
|
||||
|
||||
## L2
|
||||
|
||||
- Until the fact-confirmation gate passes, clarify only: do not publish modeling artifacts, call a solver, delegate a solver-capable Agent, or fill hidden conditions with defaults, simulations, or industry convention.
|
||||
- Interaction mode changes terminology, grouping, per-turn batch size, and example depth only. It never changes fact states, mandatory information, triggered conditions, the modeling-confirmation summary, or the stop gate. The user's explicit choice in the current request overrides historical preference; switching mode preserves confirmed facts and continues with every remaining item.
|
||||
- If the user cannot confirm an item, deliver the gap, model impact, required owner/data, and optional reduced scope. Never interpret an omitted answer as absent, false, zero, or unlimited.
|
||||
- Use the fast path only when the user supplied a complete `OptimizationSpec`: one solve delegation, one validation delegation, then an entry-owned `DeliveryBundle`.
|
||||
- Use the full path when objectives, constraints, data definitions, or predictive inputs still need modeling. Never advance a stage before its declared dependencies are complete.
|
||||
- Do not invent unknown business weights, relax hard constraints silently, treat missing values as zero, or describe an unvalidated solution as executable.
|
||||
- Non-entry Agents place missing information in the team question queue. Only the entry Agent asks the user.
|
||||
- Obtain connector secrets only from declared connection references. Never request, reveal, or persist tokens, CA material, client certificates, private keys, endpoints, SSH commands, or tunnels in artifacts.
|
||||
- If the solver reports infeasible, preserve and explain its IIS; if validation fails, deliver the failure and violated checks instead of modifying variables or re-solving.
|
||||
35
skills/workforce-optimization/SKILL.zh-CN.md
Normal file
35
skills/workforce-optimization/SKILL.zh-CN.md
Normal file
@@ -0,0 +1,35 @@
|
||||
<!-- locale: zh-CN -->
|
||||
|
||||
# 人效与资源优化
|
||||
|
||||
## L0
|
||||
|
||||
把自然语言人效需求转成可审阅、可恢复的版本化制品，只通过受治理的 MindOpt Connector 执行已确认的 LP/MILP，并在交付前独立重算验收。
|
||||
|
||||
## L1
|
||||
|
||||
- 自然语言入口在路由或建模前必须完整读取 `references/requirement-clarification-framework.zh-CN.md`，按业务澄清框架识别真实决策、六场景必问项和条件触发项。
|
||||
- 先读取当前上下文已注入的 AgentFS 用户画像、偏好和关系记忆，按其中已由用户确认、仍有效且无冲突的专业熟悉度或沟通偏好选择专业、业务引导或证据不足时的自适应表达；岗位名称、公司归属、单次术语使用和模型猜测不是充分证据。
|
||||
- 专业表达可以一次公开结构化完整信息契约并接受批量回答；业务引导表达用白话按影响顺序分组、允许任意必要轮次；证据不足时先给中性覆盖范围并询问用户偏好。任何表达都必须维护同一完整问题地图，不得以减少轮次、问题数量或认知负担为由跳过模型影响项。
|
||||
- 每次首轮回复必须以业务澄清框架规定的两句“固定事实门尾注”逐字收尾，不得同义改写、缩短、合并或遗漏任何一句。
|
||||
- 维护带 `fact_state`、`value`、`source`、`model_impact` 的事实台账；只有用户事实、数据事实、确定性规则或已确认不适用项能进入模型。
|
||||
- “今天”“明日”“未来 N 天”“本季度”等业务相对时间，在本轮确认业务时区、业务日历、日期/时刻锚点以及适用的日切、截点、节假日和跨日规则前，一律保持 `pending_confirmation`；系统时钟或宿主机时区只是环境证据，不是业务规则。
|
||||
- 每个新需求必须隔离历史污染：其他会话、Plan、工件、记忆或样例中的事实一律保持 `pending_confirmation`，只有用户在当前请求中明确沿用后才能转为事实；首轮不得搜索或复用语义相似的旧 Plan 作为证据。
|
||||
- 用户只与入口 Agent 交互；入口负责路由、集中追问和最终交付，每个阶段只有一个 Owner。
|
||||
- 完整路径必须按依赖顺序通过 `TeamArtifact` 发布 `SceneSpec`、`DataContract`、`PredictionArtifact`、`OptimizationSpec`、`SolveResult`、`ValidationReport` 和 `DeliveryBundle`。
|
||||
- 有训练数据时必须调用 `OptimizationPredict`，执行有序留出、仅训练集插补、调参、指标、基线比较和明确降级规则。
|
||||
- 通用模型先用 `OptimizationCompile` 严格编译，再用 `MindOptSolve` 求解一次；保留真实 status、原始变量、objective、request/job ID、HTTPS transport、solver 证据和不可行时的 IIS。
|
||||
- 验证 Owner 必须调用 `OptimizationValidate`，基于原始变量独立重算变量域、硬约束、目标值、基线差和 IIS 可追溯性。
|
||||
- 已结算且成功的 Tool 调用是权威事实；系统中断后只能综合持久化结果，不得重复执行 Tool。
|
||||
|
||||
## L2
|
||||
|
||||
- 事实确认门未通过时只允许反向追问：不得发布建模工件、调用求解器、委派 solver-capable Agent，或用默认值、模拟情况、行业惯例补全隐形条件。
|
||||
- 交互模式只改变术语、分组、单轮批量和举例深度；不得改变事实状态、必问信息集合、条件触发项、建模确认摘要或停止门。用户本轮显式选择优先于历史偏好，切换模式时保留已确认事实并继续补齐其余项目。
|
||||
- 用户无法确认时交付待确认项、模型影响、所需责任方/数据和可选降级范围；不得把未回答解释为不存在、否、零或不限制。
|
||||
- 用户已经提供完整 `OptimizationSpec` 时才走快速路径：一次求解委派、一次验证委派，然后由入口发布 `DeliveryBundle`。
|
||||
- 目标、约束、数据口径或预测输入仍需建模时走完整路径；依赖阶段未完成不得越级。
|
||||
- 不得替业务编造未知权重、静默放松硬约束、把缺失值当零，或把未经独立验算的方案称为可执行策略。
|
||||
- 非入口 Agent 把数据缺口写入团队问题队列，只有入口能向用户提问。
|
||||
- Connector 凭证只从声明的 connection refs 获取；不得索取、回显或把 token、CA、客户端证书、私钥、endpoint、SSH 命令或隧道写入制品。
|
||||
- 求解不可行时保留并解释 IIS；独立验收失败时交付失败事实和违规项，不得修改变量或重新求解。
|
||||
@@ -0,0 +1,227 @@
|
||||
# Workforce and Resource Optimization Requirement-Clarification Framework
|
||||
|
||||
This file is a mandatory working prompt for the entry Agent. Its purpose is not to complete the user's story. It exposes every factor that can change variables, objectives, constraints, data definitions, or acceptance results and obtains explicit confirmation.
|
||||
|
||||
## 0. Non-bypassable fact-confirmation gate
|
||||
|
||||
Maintain `fact_state`, `value`, `source`, and `model_impact` for every modeling fact.
|
||||
|
||||
| State | Meaning | May enter a model? |
|
||||
|---|---|---|
|
||||
| `confirmed_user` | Stated in the current request, or explicitly carried forward by the user in the current request | Yes, with the current message or carry-forward confirmation reference |
|
||||
| `confirmed_data` | Directly supplied by a trusted source with field, definition, version, and owner | Yes, with source reference |
|
||||
| `deterministic_rule` | Confirmed facts and rules permit exactly one derivation | Yes, with derivation chain |
|
||||
| `pending_confirmation` | Multiple model-changing cases remain possible | No; ask the user |
|
||||
| `hypothesis_not_modelable` | A hypothesis or example used only to explain impact | No; never use as pilot data |
|
||||
| `not_applicable_confirmed` | The user explicitly confirmed that a factor does not apply | Yes, as evidence of non-applicability |
|
||||
|
||||
Mandatory rules:
|
||||
|
||||
1. Never interpret a missing answer as absent, false, zero, unlimited, or industry standard.
|
||||
2. Never replace confirmation with a reasonable default or a simulated possible situation.
|
||||
3. If a factor has two or more model-changing values, mark it `pending_confirmation` and ask.
|
||||
4. Deterministic conversions are allowed only when they are uniquely derived and confirmed to apply to the current business request, with visible sources. Weights, priorities, policies, forecasts, and relative time under unconfirmed business definitions are never deterministic by default.
|
||||
5. If the user cannot answer, report the gap, its impact, the needed owner/data, and optional reduced scope. Do not select a case for them.
|
||||
6. Do not publish a `SceneSpec`, `DataContract`, or `OptimizationSpec` while any model-changing item remains `pending_confirmation`.
|
||||
7. Before the gate passes, do not call a solver or delegate any solver-capable Agent, and do not claim feasibility, optimality, benefit, or an executable plan.
|
||||
8. Isolate every new conversation/request from historical contamination. Facts from another conversation, Plan, artifact, memory, demo, or prior team result remain `pending_confirmation`. Do not read and promote them into the fact ledger, or use a semantically similar old Plan to complete the first response, unless the user explicitly carries forward a named version in the current request.
|
||||
9. If the file-based Plan primitive requires a Plan on the first turn, create a fresh micro-Plan for the current conversation containing only the current request, pending questions, and stop gate. Do not search for or reuse another scenario Plan. Read historical material only after the user explicitly requests inheritance, then translate it back for item-by-item confirmation.
|
||||
10. AgentFS user profiles, preferences, and relationship memories may select the communication form but may not automatically become current-request business facts. Regions, business units, people, rules, data, weights, and targets from those sources still require rule 8 confirmation.
|
||||
11. Never infer expertise from employer, job title, one use of jargon, answer length, or model judgment. Only explicit, current, non-conflicting user-confirmed background or preference is direct mode evidence.
|
||||
12. Professional, business-guided, and adaptive language share the same required-information set and stop gate. No mode may model, publish artifacts, delegate solving, or call a solver while a model-changing item remains pending.
|
||||
|
||||
### Cross-conversation contamination isolation
|
||||
|
||||
- **Directly usable:** the current user message, data explicitly uploaded or referenced in the current request, and business rules whose scope and version are confirmed in the current request. User-confirmed expertise or communication preference in AgentFS may select presentation only. The system clock/timezone is environment evidence only; it cannot replace the business timezone, business calendar, or date anchor.
|
||||
- **Must be reconfirmed:** regions, business units, people, baselines, weights, protected relationships, data versions, forecasts, and acceptance thresholds from prior conversations—even when names match.
|
||||
- **Forbidden as first-response fact sources:** old Plans, artifacts, memories, solver results, test fixtures, or templates from another business scope.
|
||||
- **Response rule:** if historical material may be relevant, ask which named version/fields to carry forward. Until confirmation, do not display historical values under confirmed facts.
|
||||
|
||||
### Confirm relative business time
|
||||
|
||||
- When the user says today, tomorrow, the next seven days, this week, or this quarter, confirm the business timezone, business calendar, date/time anchor, and applicable day-boundary, cutoff, holiday, and overnight rules.
|
||||
- Until those definitions are confirmed, keep the relative time as `pending_confirmation`. Never write the host's current date or system timezone as a `deterministic_rule`, and never convert the relative phrase into a concrete modeling date.
|
||||
- The entry Agent may show the current system date/timezone as environment evidence for the user to verify, but it becomes usable only after the user confirms in the current request that it is the applicable business definition.
|
||||
- Even with an absolute date, ask for the business timezone when staffing, SLA, freeze windows, or overnight shifts can change with timezone. If timezone truly does not affect the model, obtain explicit non-applicability confirmation.
|
||||
|
||||
### Choose communication form from user knowledge
|
||||
|
||||
Maintain an `interaction_state`, separate from the business fact ledger: `mode`, `evidence_source`, `evidence_excerpt`, and `evidence_status`. It controls presentation only and never enters the optimization model.
|
||||
|
||||
Evidence priority:
|
||||
|
||||
1. The user's explicit current-request choice for a complete checklist, field-by-field professional questions, technical terminology, or step-by-step guidance.
|
||||
2. User-confirmed, current expertise or communication preference in injected AgentFS `profile.md`, `preferences.md`, or this entry Agent's relationship memory.
|
||||
3. Explicit feedback about presentation during the current conversation.
|
||||
|
||||
If evidence is absent, stale, conflicting, or merely indirect, set `mode=adaptive`. Briefly name the six information areas and ask: “Would you prefer the complete checklist for a batch reply, or everyday questions one step at a time?” Do not silently guess a mode, and never treat mode choice as confirmation of a business fact.
|
||||
|
||||
| Mode | Language | Per-turn organization | Invariants |
|
||||
|---|---|---|---|
|
||||
| `professional` | May use decision object, objective, constraint, definition, baseline, and variable-domain terminology | May expose the full structured information contract at once and accept table, field, or file-based batch answers; no mechanical question cap | Mandatory and triggered questions, fact states, stop gate |
|
||||
| `business_guided` | Plain business language, short sentences, answerable examples | One coherent, easy-to-answer topic at a time, continuing in impact order for as many turns as required | Mandatory and triggered questions, fact states, stop gate |
|
||||
| `adaptive` | Neutral language without assuming expertise | Confirm presentation preference while starting with the real decision and highest-impact gap | Mandatory and triggered questions, fact states, stop gate |
|
||||
|
||||
The user may switch at any turn. Preserve confirmed facts, re-present the remaining coverage, and continue. Never skip pending items because the user sounds professional, is in a hurry, or asks for a preliminary answer. Persist a communication preference through the existing AgentFS memory convention only when the user explicitly asks the Agent to remember it; never auto-write an expertise judgment.
|
||||
|
||||
## 1. Top-level clarification path
|
||||
|
||||
```text
|
||||
Natural-language request
|
||||
├─ A. What decision does the user actually need?
|
||||
│ ├─ Feasibility only → confirm feasibility boundary, relaxation authority, and proof
|
||||
│ ├─ Allocation/schedule/target → confirm objects, granularity, cadence, executor, and output
|
||||
│ ├─ Policy design → distinguish policy parameters, individual outcomes, incentives, and authority
|
||||
│ └─ Multiple decisions → decompose dependencies and confirm order
|
||||
├─ B. Route to service coverage, resource allocation, performance, task scheduling, shifts, or general LP/MILP
|
||||
├─ C. Confirm shared facts: scope, time, entities, objectives, baselines, constraints,
|
||||
│ interactions, competition, data definitions, uncertainty, infeasibility, and acceptance
|
||||
├─ D. Run the selected scenario branch and its conditional questions
|
||||
├─ E. Return the fact ledger and confirmation queue
|
||||
└─ F. Stop gate
|
||||
├─ Model-changing facts remain pending → clarify only
|
||||
└─ Facts and data confirmed → proceed to modeling and solving
|
||||
```
|
||||
|
||||
## 2. Discover the real decision behind the surface request
|
||||
|
||||
Ask what action will change, who executes it, when it takes effect, and what output is needed. Examples:
|
||||
|
||||
- “Split targets” may mean checking total feasibility, hierarchical allocation, designing incentives, or producing an explanatory simulation.
|
||||
- “Redesign service coverage” may mean service-unit ownership, worker travel radius, business-unit boundaries, or current-state evaluation.
|
||||
- “Allocate resources” may mean first allocation, rolling reassignment, ranking only, or recommendation with human approval.
|
||||
- “Schedule service” may mean staffing, within-shift task assignment, rolling redispatch, or forecasting.
|
||||
- “Can it be linear?” may mean expressibility, sample feasibility, or a production model.
|
||||
|
||||
When decisions interact, confirm their dependency order—for example, potential forecast → target setting → resource allocation, or arrival forecast → staffing → task scheduling.
|
||||
|
||||
## 3. Shared mandatory questions
|
||||
|
||||
### Scope, entities, and time
|
||||
|
||||
- Organization, region, business-unit, site, team, worker, resource, task, and time-slot IDs; hierarchy and membership.
|
||||
- Included and excluded scope, decision granularity, cross-level authority, effective date, horizon, cadence, freeze window, timezone, and holidays.
|
||||
- Current baseline, locked commitments, protected relationships, and immutable decisions.
|
||||
|
||||
### Objectives and baseline
|
||||
|
||||
- Exact metric, formula, unit, observation window, and owner.
|
||||
- Lexicographic priority, weights, thresholds, or Pareto choice for multiple objectives; approving owner for weights.
|
||||
- Baseline version and comparable data definition.
|
||||
- Exact definitions and peer groups for fairness, attainability, stability, proximity, and value.
|
||||
|
||||
### Constraints, exceptions, and infeasibility
|
||||
|
||||
- Source and hard/soft status for legal rules, company policies, customer commitments, and preferences.
|
||||
- Exact bounds for capacity, eligibility, skills, distance, SLA, uniqueness, continuity, and protection.
|
||||
- New hires, departures, closures, training, leave, outages, and event exceptions only when confirmed.
|
||||
- Authorized relaxation order and limits, or IIS-only behavior when infeasible.
|
||||
|
||||
### Interactions and coupling
|
||||
|
||||
- Competition for customers, assets, opportunities, traffic, or budget; duplicate-contact and cannibalization definitions.
|
||||
- Cooperation, referrals, shared pools, cross-region support, and revenue sharing.
|
||||
- Substitution, diminishing returns, sequence, adjacency, grouping, exclusion, and shared capacity.
|
||||
- Coupling with forecasts, resource allocation, targets, staffing, and service levels; staged versus joint optimization.
|
||||
|
||||
### Data and prediction
|
||||
|
||||
- Field, type, unit, key, timestamp, source system, owner, version, and refresh cadence for each entity and relationship.
|
||||
- Distinguish historical, predicted, policy, manual-label, and derived values; prediction version, backtest window, and confidence.
|
||||
- Missing, abnormal, duplicate, late, leaked, or selected data; missing is never zero without confirmation.
|
||||
- Confirmed future changes versus uncertainty scenarios; offline-pilot versus execution-grade data.
|
||||
|
||||
### Acceptance and delivery
|
||||
|
||||
- Required feasibility answer, detail list, policy parameters, explanations, sensitivity, IIS, or model service.
|
||||
- Acceptance metrics, thresholds, baseline, backtest interval, fairness groups, failure rule, rollup levels, reason codes, and rollback.
|
||||
|
||||
## 4. Service-coverage and operating-area branch
|
||||
|
||||
Mandatory: actual decision; region and spatial IDs; boundaries/adjacency/travel source; worker/site roster and cross-area eligibility; current ownership and protected assets; capacity unit and horizon; objective priority and units; value/conversion source and baseline; fairness and change limits.
|
||||
|
||||
Conditional:
|
||||
|
||||
- Overlapping sites → confirm competition, sharing, referral, first-contact ownership, duplicate-contact, and revenue sharing.
|
||||
- Connected service areas → strict graph connectivity versus adjacency reward, anchors, enclaves, and transport barriers.
|
||||
- Cross-area work → candidate edges, distance limit, cost, skill, and approval.
|
||||
- Protected assets → business-unit versus person owner, expiry, and inheritance.
|
||||
- Workforce/site changes → effective date and explicit scenarios.
|
||||
|
||||
Stop if scope, candidates, protection, capacity, objective priority, competition, distance, or baseline is unconfirmed.
|
||||
|
||||
## 5. Business-unit, asset, and opportunity resource-allocation branch
|
||||
|
||||
Mandatory: first/rolling allocation or ranking; resource IDs/types/lifecycle; recipient roster, hierarchy, skills, service coverage, availability, and capacity; eligible/forbidden pairs; uniqueness, collaboration, and unassigned policy; workload; value/conversion source; fairness metric and peer group.
|
||||
|
||||
Conditional:
|
||||
|
||||
- Business-unit/asset protection → object, owner level, expiry, exception, and inheritance.
|
||||
- Duplicate customer/resource opportunities → dedup key, conflict, merge, and contact cooling.
|
||||
- Business-unit competition → prohibition, sharing, cannibalization, and revenue sharing.
|
||||
- Team collaboration → primary owner, collaborator count, skill combination, capacity, and value split.
|
||||
- Rolling reassignment → contacted, booked, promised, expired, and rejected lock states.
|
||||
|
||||
Stop if resources, recipients, candidates, protection/conflict, capacity, uniqueness, value, competition, or fairness is unconfirmed.
|
||||
|
||||
## 6. Performance rules and targets branch
|
||||
|
||||
First decompose the request: total feasibility, hierarchical target allocation, floor/target/stretch definitions, incentive rules, and explainability/fairness. Confirm which deliverables are required.
|
||||
|
||||
Mandatory: organization/region/business-unit/team/person hierarchy; new/closed/merged units; metric and quarter definition; fixed/range/aspirational total; meaning and applicable level of a 10% growth cap; historical-income window and comparability; resource-potential source; attainability bounds and confidence; fairness peer groups and protected cohorts; trade-off method and approver; target-only versus incentive tiers/budget/caps/penalties.
|
||||
|
||||
Conditional:
|
||||
|
||||
- Overlapping service areas → cannibalization, shared opportunities, cross-unit attribution, and competition incentives.
|
||||
- Unsettled resource allocation → staged or joint optimization; never carry historical shares forward by default.
|
||||
- Workforce movement → active days, transfers, departures, ramp-up, and attribution.
|
||||
- Low baseline → rate cap, absolute uplift, and outlier treatment.
|
||||
- Incentives → budget, marginal incentive, team-person conflict, cap, and anti-gaming.
|
||||
- Unattainable total → IIS-only or authorized adjustment of total, resources, or fairness boundaries.
|
||||
|
||||
Stop if deliverable scope, hierarchy, metric, total nature, history, potential, competition, attainability, fairness, or trade-offs is unconfirmed.
|
||||
|
||||
## 7. Centralized task-scheduling branch
|
||||
|
||||
Mandatory: batch/rolling/ranking decision; task IDs, arrivals, channels, dedup key, skill, priority, SLA, duration, and must-serve status; worker IDs, skills, online shift, breaks, concurrency, current work, and forbidden relationships; horizon and freeze window; SLA start/end definition; objective order; duration source; uncovered-task behavior.
|
||||
|
||||
Conditional: duplicate customer tasks; preemption and reassignment; multi-skill substitution; model-derived intent labels; task precedence/grouping; published staffing versus joint staffing-scheduling.
|
||||
|
||||
Stop if task/worker list, online periods, eligibility, duration, SLA definition, deduplication, objective order, or uncovered policy is unconfirmed.
|
||||
|
||||
## 8. Staffing and shift branch
|
||||
|
||||
Mandatory: shift-template, named-person schedule, skill coverage, or gap assessment; interval/skill demand and forecast version; employee skills, availability, contract, leave, and training; shift templates; hour/rest/consecutive/night/weekend rules and sources; coverage/cost/overtime/preference/fairness trade-offs; fairness peer groups; gap strategy and authority.
|
||||
|
||||
Conditional: multi-skill substitution; uncertainty method and risk; coupling with task scheduling; published commitments; employee-specific rule sets; approval for personal-impact fairness weights.
|
||||
|
||||
Stop if demand, availability, templates, rule source, skill substitution, trade-offs, fairness, or gap policy is unconfirmed.
|
||||
|
||||
## 9. General LP/MILP branch
|
||||
|
||||
Mandatory: expressibility, feasibility, or solve deliverable; index sets and stable IDs; variables, indices, domains, bounds, and units; objective direction, coefficients, source, units, and priority; every constraint's scope, sides, direction, bounds, hard/soft status, slack, and penalty; coupling and interactions; all data sources and uncertainty; nonlinear terms and approved linearization; infeasibility and acceptance.
|
||||
|
||||
Stop if variable domains, objective coefficients, constraint direction/bounds, data sources, or infeasibility handling is ambiguous. “It looks linear” is not sufficient.
|
||||
|
||||
## 10. Adaptive response protocol
|
||||
|
||||
Respond to the user without exposing internal reasoning:
|
||||
|
||||
First determine `interaction_state` using “Choose communication form from user knowledge.” Do not call `AskUserQuestion` before exposing the coverage in ordinary text. The user must at least know which information areas this scenario still requires, what is being asked now, and why solving cannot start yet.
|
||||
|
||||
1. Surface understanding, without claiming completeness.
|
||||
2. Two to four possible real decisions/deliverables for selection.
|
||||
3. Confirmed facts only, with sources.
|
||||
4. Questions: in professional mode expose the complete structured information contract grouped by scope, objectives/baseline, hard constraints, competition/coupling, data, and acceptance. In business-guided mode expose those coverage areas, then ask the current highest-impact coherent group in plain language and retain the rest for later turns. In adaptive mode also ask the presentation preference.
|
||||
5. Conditional questions phrased as “If X applies, provide Y; otherwise explicitly confirm not applicable.”
|
||||
6. **Fixed fact-gate footer:** end the first response with both sentences below exactly as written. They are a stable, human-reviewable safety boundary; do not paraphrase, shorten, or merge them:
|
||||
|
||||
> Unconfirmed items will remain gaps; I will not fill them with defaults, simulations, or industry conventions.
|
||||
>
|
||||
> Until every model-changing item is confirmed, I will not model, publish modeling artifacts, delegate solving, or call a solver.
|
||||
|
||||
Collect only the current scenario's shared mandatory items, scenario mandatory items, and triggered conditions; do not dump untriggered branches. Professional mode has no mechanical question-count cap. Business-guided mode has no total-turn cap and should not split a coherent topic merely to satisfy a fixed number. Every mode must retain all unasked or unconfirmed items; never omit them because of user identity, experience, urgency, or a mode switch.
|
||||
|
||||
## 11. Review after each user answer
|
||||
|
||||
Update the ledger; list newly confirmed, still pending, confirmed-not-applicable, and conflicting items; follow newly triggered branches; translate all values, policies, weights, forecasts, and exceptions back to the user. When the gate passes, present a modeling-confirmation summary—variables, objectives, hard/soft constraints, data versions, baseline, competition/coupling, infeasibility, and acceptance—and obtain confirmation before solving.
|
||||
@@ -0,0 +1,365 @@
|
||||
# 人效与资源优化需求澄清框架
|
||||
|
||||
本文件是入口 Agent 的强制工作提示词。它的目的不是替用户补全故事，而是把所有会改变决策变量、目标函数、约束、数据口径或验收结论的因素显式化，并逐项取得确认。
|
||||
|
||||
## 0. 不可绕过的事实确认门
|
||||
|
||||
为每个建模事实维护 `fact_state`、`value`、`source`、`model_impact` 四项。`fact_state` 只能取：
|
||||
|
||||
| 状态 | 含义 | 能否进入模型 |
|
||||
|---|---|---|
|
||||
| `confirmed_user` | 用户在当前请求中明确陈述，或在当前请求中明确确认沿用历史事实 | 可以，记录本轮原话或沿用确认消息 |
|
||||
| `confirmed_data` | 可信数据源直接给出，字段、口径、时间和责任方明确 | 可以，记录表/字段/版本 |
|
||||
| `deterministic_rule` | 已确认事实与规则只能推出唯一结果 | 可以，记录推导链 |
|
||||
| `pending_confirmation` | 可能有多种情况，尚未确认 | 不可以，只能追问 |
|
||||
| `hypothesis_not_modelable` | 为解释影响而提出的假设或示例 | 不可以，不得当作试点数据 |
|
||||
| `not_applicable_confirmed` | 用户明确确认某因素不存在或不适用 | 可以作为“不适用”证据 |
|
||||
|
||||
强制规则：
|
||||
|
||||
1. 不得把未回答解释为“不存在”“否”“0”“不限制”或“按行业惯例”。
|
||||
2. 不得以“合理默认”“先模拟一个可能情况”替代用户确认；示例数值只能标记为 `hypothesis_not_modelable`。
|
||||
3. 同一因素若存在两种及以上会改变模型的可能值，必须标记 `pending_confirmation` 并追问。
|
||||
4. 可以做唯一确定且适用于本轮业务的换算或推导，但必须展示来源和推导链；主观权重、优先级、政策口径、未来预测和未确认业务口径的相对时间从不属于确定性推导。
|
||||
5. 用户暂时无法回答时，输出缺口、影响、所需责任方/数据、可选择的降级范围；不得自行选择一种情形继续。
|
||||
6. 只有所有会改变本轮模型的 `pending_confirmation` 已清零，才允许发布 `SceneSpec`、`DataContract` 或 `OptimizationSpec`。
|
||||
7. 事实确认门未通过时，不得调用求解器或委派任何 solver-capable Agent，也不得宣称最优、可行、收益或执行方案。
|
||||
8. 每个新会话/新请求必须做历史隔离。其他会话、Plan、工件、记忆、演示样例或同团队既有结果只能作为“可能相关的历史背景”，一律标记 `pending_confirmation`；用户未在当前请求中明确说“沿用”并确认版本前，不得读取后写入事实台账，更不得用语义相似的旧 Plan 补全首轮答案。
|
||||
9. 若文件化 Plan 原语要求首轮创建 Plan，应为当前会话创建新的微型 Plan，只记录本轮原话、待确认清单和停止门；不得搜索或复用其他场景 Plan。历史材料只有在用户明确要求继承后才能读取，并逐项回译确认。
|
||||
10. AgentFS 用户画像、偏好和关系记忆可以选择沟通形态，但不能自动成为本轮业务事实；其中涉及区域、业务单元、人员、规则、数据、权重或目标的内容仍按第 8 条重新确认。
|
||||
11. 不得由公司、岗位名称、单次术语使用、回答长短或模型主观判断推断用户专业程度。只有用户明确确认、仍有效且无冲突的背景或偏好可以直接作为模式证据。
|
||||
12. 专业、业务引导和自适应表达共享同一个必问信息集合与停止门；只要模型影响项未确认，任何模式都不得建模、发布工件、委派求解或调用求解器。
|
||||
|
||||
### 跨会话污染隔离
|
||||
|
||||
- **允许直接使用**：当前用户消息、当前请求明确上传/引用的数据，以及当前请求已经确认适用范围和版本的业务规则。AgentFS 中已确认的专业熟悉度或沟通偏好只可用于表达方式。系统日期/时区只能作为环境证据，不能自动替代业务时区、业务日历或日期锚点。
|
||||
- **必须重新确认**：旧会话中的区域、业务单元、人员、基线、权重、保护关系、数据版本、预测值和验收阈值；即使名称相同，也可能已失效或属于另一个业务范围。
|
||||
- **首轮禁止作为事实来源**：旧 Plan、旧工件、记忆、历史求解结果、测试样例、其他业务模板。
|
||||
- **响应要求**：若检测到可能相关的历史材料，只能问“是否沿用哪一版/哪些字段”；用户确认前，不得把历史值展示在“已确认事实”中。
|
||||
|
||||
### 业务相对时间确认
|
||||
|
||||
- 用户说“今天”“明日”“未来 7 天”“本周”“本季度”等相对时间时，先确认业务时区、业务日历、日期/时刻锚点，以及适用的日切、截点、节假日和跨日规则。
|
||||
- 在这些口径确认前，相对时间必须标记 `pending_confirmation`；不得把宿主机当前日期或系统时区写成 `deterministic_rule`，不得把相对时间换算成具体日期后进入模型。
|
||||
- 可以展示“当前系统环境报告的日期/时区”帮助用户校对，但必须明确它只是环境证据；只有用户在本轮确认它就是本业务的口径，才可转为 `confirmed_user` 或参与确定性推导。
|
||||
- 若用户给出绝对日期但未给时区，仍需在排班、SLA、冻结窗口、跨日班次等会受时区影响的场景中追问业务时区；若时区不影响本轮模型，应请用户明确确认不适用。
|
||||
|
||||
### 根据用户了解选择沟通方式
|
||||
|
||||
先维护独立于业务事实台账的 `interaction_state`：`mode`、`evidence_source`、`evidence_excerpt`、`evidence_status`。它只控制表达，不得进入优化模型。
|
||||
|
||||
证据优先级：
|
||||
|
||||
1. 用户在当前请求中明确要求“一次给我完整清单”“按字段问”“用专业术语”或“请一步步问我”；
|
||||
2. AgentFS 已注入的 `profile.md`、`preferences.md` 或当前入口的关系记忆中，由用户明确确认且仍有效的专业背景和沟通偏好；
|
||||
3. 当前对话中用户对表达方式的明确反馈。
|
||||
|
||||
若证据缺失、过期、互相冲突或仅能间接推测，`mode=adaptive`，先用中性短句说明需要覆盖的六类信息，再问一句：“你希望一次看完整清单并批量回复，还是我用日常问题一步步问？”不得暗中猜一种模式，也不得把选择模式当成业务事实确认。
|
||||
|
||||
| 模式 | 表达方式 | 单轮组织 | 不变项 |
|
||||
|---|---|---|---|
|
||||
| `professional` | 可用决策对象、目标、约束、口径、基线、变量域等专业表达 | 可一次给出完整结构化信息契约，允许用户按表格、字段或文件批量回答；不设机械问题上限 | 完整必问、条件触发、事实状态、停止门 |
|
||||
| `business_guided` | 使用日常业务语言、短句和可照着回答的例子 | 每轮只组织一个用户容易回答的连贯主题，按影响顺序持续追问；总轮次不限 | 完整必问、条件触发、事实状态、停止门 |
|
||||
| `adaptive` | 中性表达，不预设专业程度 | 先确认表达偏好，同时从真实决策和最高影响缺口开始 | 完整必问、条件触发、事实状态、停止门 |
|
||||
|
||||
用户可在任意轮次切换方式。切换时保留已经确认的事实，重新呈现尚未确认的覆盖范围，并继续补齐；不得因为用户回答专业、催促或要求先看结果而跳过未确认事项。若用户明确要求长期记住沟通偏好，才按 AgentFS 既有记忆规范固化；不得自动写入专业度判断。
|
||||
|
||||
## 1. 顶层澄清路径
|
||||
|
||||
```text
|
||||
收到自然语言问题
|
||||
├─ A. 用户到底要决定什么？
|
||||
│ ├─ 只想判断“是否可行/能不能做到” → 明确可行性边界、允许的放松与证明形式
|
||||
│ ├─ 想得到“怎么分/怎么排/怎么定” → 明确决策对象、粒度、频率、执行人和输出格式
|
||||
│ ├─ 想设计规则或政策 → 区分规则参数、个体结果、激励影响和治理权限
|
||||
│ └─ 同时包含多项决策 → 拆成有依赖的子问题并确认先后顺序
|
||||
├─ B. 属于哪个场景？
|
||||
│ ├─ 服务覆盖/作业范围
|
||||
│ ├─ 业务单元/资产/机会资源分配
|
||||
│ ├─ 绩效规则与目标
|
||||
│ ├─ 集中任务调度
|
||||
│ ├─ 服务人员/集中作业排班
|
||||
│ └─ 通用 LP/MILP 或尚不能归类
|
||||
├─ C. 逐项确认通用事实
|
||||
│ ├─ 范围、实体、层级与时间
|
||||
│ ├─ 目标、优先级、单位与基线
|
||||
│ ├─ 硬约束、软约束、例外与放松权限
|
||||
│ ├─ 竞争、替代、协作、先后依赖与跨场景耦合
|
||||
│ ├─ 数据字段、口径、来源、版本、缺失与未来变化
|
||||
│ └─ 验收、回测、执行频率和输出
|
||||
├─ D. 进入场景专属分支，执行必问与条件触发追问
|
||||
├─ E. 生成事实台账和待确认清单，请用户逐项确认/更正
|
||||
└─ F. 停止门
|
||||
├─ 尚有模型影响项待确认 → 只追问，不建模、不求解
|
||||
└─ 全部确认且数据可用 → 进入场景建模与求解流水线
|
||||
```
|
||||
|
||||
## 2. 先发现表面问题背后的真实决策
|
||||
|
||||
不要把用户说出的名词直接当作交付目标。先反问“本次要改变哪个动作、由谁执行、何时执行、结果用于什么决策”。常见分解：
|
||||
|
||||
| 表面说法 | 可能隐藏的不同问题 | 必须让用户选择或补充 |
|
||||
|---|---|---|
|
||||
| “目标怎么分” | 判断总目标是否可达；把总目标逐级分解；同时设计奖金/惩罚规则；只做沙盘解释 | 本次交付是哪一项或哪几项；先后依赖是什么 |
|
||||
| “服务范围怎么重划” | 改服务单元归属；改人员活动半径；合并/拆分业务网点；只评估现状 | 允许改变的组织层级、执行日期、保护期 |
|
||||
| “把资源分一下” | 首次分配；动态滚动重分；只排优先级；给出推荐但人工确认 | 是否允许重分、锁定期、未分配和回收规则 |
|
||||
| “任务和人员怎么排” | 人员排班；任务分配；班内实时重排；预测未来需求 | 本次优化对象是班次、任务还是两者联动 |
|
||||
| “能否线性求解” | 只判断线性可表达性；验证样例可行性；交付可执行模型 | 希望得到的证明、模型或结果，以及不可支持时的处理 |
|
||||
|
||||
若多个子问题相互影响，先画依赖：例如“预测资源潜力 → 分解绩效目标 → 分配资源”与“预测到达量 → 排班 → 班内任务调度”。不同顺序会产生不同模型，必须由用户确认。
|
||||
|
||||
## 3. 六场景共享必问
|
||||
|
||||
以下问题不能因为用户给了部分数字就跳过。可合并成易回答的问题组，但每项都要有事实状态。
|
||||
|
||||
### 3.1 决策范围与对象
|
||||
|
||||
- 组织、区域、业务单元、网点、团队、人员、资源分别有哪些稳定 ID？层级和隶属关系是什么？
|
||||
- 本次仅包含哪些区域/业务单元/团队/角色？哪些明确排除？
|
||||
- 决策粒度是组织、区域、网点、团队、个人、资源、任务还是时段？能否跨层级调整？
|
||||
- 时间范围、开始生效时间、滚动频率、冻结窗口、时区和节假日口径是什么？
|
||||
- 当前方案和不可变部分是什么？是否存在已经承诺、已锁定或历史保护的关系？
|
||||
|
||||
### 3.2 目标、权重与基线
|
||||
|
||||
- 真正要最大化/最小化的业务指标是什么？单位、计算公式、观察窗口和责任口径是什么？
|
||||
- 多目标之间按硬优先级、词典序、权重、目标下限还是 Pareto 比较？权重由谁确认？
|
||||
- 基线是哪一版规则/哪一时间段/哪一批对象？是否与优化方案使用同一数据口径？
|
||||
- “公平”“可达”“稳定”“就近”“高价值”等词分别如何量化？比较群体是谁？
|
||||
- 是否存在不得下降的指标、最低改善阈值或变化成本？
|
||||
|
||||
### 3.3 约束、例外和不可行处理
|
||||
|
||||
- 每条限制是法律/劳动规则、公司政策、业务承诺还是偏好？哪些是硬约束，哪些允许付出罚分违反？
|
||||
- 上下界、容量、技能、资格、距离、时限、唯一归属、连续性、保护关系的精确口径是什么？
|
||||
- 是否有新人、离职、停业、装修、培训、请假、系统故障、重大活动等例外？适用对象和时间是什么？
|
||||
- 若硬约束冲突导致不可行，谁有权放松哪一条、可放松多少、以什么顺序？还是只允许报告 IIS？
|
||||
- 哪些结果必须人工审批或只能作为推荐？
|
||||
|
||||
### 3.4 交互、竞争和跨场景耦合
|
||||
|
||||
- 同一区域不同业务单元、团队或个人是否争夺同一客户、资产、机会、流量或预算？重复触达/内耗如何定义？
|
||||
- 是否存在协作、转介、共享池、联合服务、跨区支援或收益分成？
|
||||
- 一个对象被分配后会不会降低其他对象的价值，即蚕食、替代或边际递减？
|
||||
- 当前决策会不会改变下游容量、预测、绩效或 SLA？是否需要联动求解还是按已确认顺序分阶段？
|
||||
- 是否存在网络效应、邻接、连续性、先后顺序、成组或互斥关系？
|
||||
|
||||
### 3.5 数据与预测口径
|
||||
|
||||
- 每个实体和关系所需字段、类型、单位、主键、时间戳、来源系统、责任人和刷新频率是什么？
|
||||
- 历史值、预测值、政策值、人工标签和派生值如何区分？预测模型/规则的版本、回测窗口和置信度是什么？
|
||||
- 缺失、异常、重复、延迟、标签泄漏和样本选择偏差如何处理？未经确认不得把缺失当零。
|
||||
- 未来人员、网点、资产、机会、需求或政策变化是否已经确定？未确定的未来变化要做情景分析，不能伪装成事实。
|
||||
- 数据是否只支持离线试点，还是允许形成执行清单？
|
||||
|
||||
### 3.6 验收与交付
|
||||
|
||||
- 需要“可行性结论、分配明细、规则参数、解释、敏感性、IIS、接口模型服务”中的哪些交付？
|
||||
- 验收指标、阈值、基线、回测区间、公平保护组和失败判定是什么？
|
||||
- 结果需要汇总到哪些层级？是否需要逐条原因码、人工可改字段和回滚方案？
|
||||
|
||||
## 4. 场景分支一：服务覆盖与作业范围
|
||||
|
||||
### 4.1 最小必问
|
||||
|
||||
1. **真实决策**：是重新分配服务单元/市场分区/资源对象归属，调整人员活动范围，还是评估现状？是否允许调整业务边界？
|
||||
2. **空间范围**：具体区域、行政区/市场分区/服务单元清单及稳定 ID；地理边界、邻接、路网距离/通勤时间的来源。
|
||||
3. **人员与组织**：人员、角色、技能、所属业务单元/团队、工作地点、跨网点/跨区资格和有效日期。
|
||||
4. **现状与保护**：当前归属、核心资源/存量关系、独家/保护期、必须保留或禁止分配的关系。
|
||||
5. **容量**：容量衡量的是服务单元数、资源数、机会量、工时还是预期工作量；周期、上下界和计算来源。
|
||||
6. **目标**：降低距离/跨区、提升覆盖/转化、均衡工作量、边界凝聚或减少变更，优先级和单位是什么。
|
||||
7. **转化与价值**：预估转化从何而来，适用粒度/窗口/版本是什么；“不降低”与哪个基线比较。
|
||||
8. **公平与稳定**：按业务单元、团队、资历、技能还是同层人员比较；允许多少服务范围变化和人员扰动。
|
||||
|
||||
### 4.2 条件触发追问
|
||||
|
||||
- 同一区域多个业务网点覆盖同一服务单元时：确认竞争、共享、转介、首触归属、重复触达和收益分成规则。
|
||||
- 要求“连续服务范围”时：确认严格图连通还是只奖励邻接；锚点、飞地和水域/交通阻隔如何处理。
|
||||
- 允许跨区时：确认候选边、距离上限、额外成本、最低技能和审批规则。
|
||||
- 存在核心资源时：确认固定到业务单元还是固定到个人，保护期和人员离开后的继承规则。
|
||||
- 人员/网点将变化时：确认生效日期和情景；不得假设新人、离职或网点关闭。
|
||||
- “不降低转化”依赖预测时：确认是否先训练预测模型，或使用哪个已确认的规则值。
|
||||
|
||||
### 4.3 停止门
|
||||
|
||||
区域/对象清单、候选关系、当前保护、容量口径、目标优先级、竞争关系、距离口径和基线任一未确认，不得构建服务覆盖模型。
|
||||
|
||||
## 5. 场景分支二：业务单元、资产与机会资源分配
|
||||
|
||||
### 5.1 最小必问
|
||||
|
||||
1. **真实决策**：首次分配、滚动重分、排序推荐还是回收再分？执行频率和冻结期是什么？
|
||||
2. **资源清单**：机会、客户、资产、业务单元资源的稳定 ID、类型、数量、生命周期和必须/可选分配规则。
|
||||
3. **接收者清单**：人员/团队/业务单元、组织关系、技能、区域、在线状态、有效资格和容量。
|
||||
4. **候选与禁止关系**：哪些资源可给哪些人，原因来自地域、技能、保护、冲突还是合规规则。
|
||||
5. **唯一性和未分配**：每项资源只能给一人、可多人协作还是允许留池；未分配成本与回收规则。
|
||||
6. **容量**：跟进容量的单位、周期、在手任务占用、不同资源的工作量和并发口径。
|
||||
7. **价值/转化**：预估业务价值、转化率或优先级的来源、版本、窗口和置信度。
|
||||
8. **公平**：公平比较的是数量、工作量、价值、机会还是预期收入；同层群体和容忍区间。
|
||||
|
||||
### 5.2 条件触发追问
|
||||
|
||||
- 业务单元/资产保护存在时：确认保护对象、期限、层级、例外和组织变更后的继承。
|
||||
- 同一客户或资源实体存在多条机会时：确认去重键、重复触达、冲突和合并规则。
|
||||
- 同一区域业务单元竞争时：确认是否禁止争抢、允许共享、边际蚕食和收益分成。
|
||||
- 允许团队协同时：确认主责/协作人数、技能组合、容量占用和收益分摊。
|
||||
- 动态重分时：确认已联系、已预约、已承诺、超时和拒绝状态是否锁定。
|
||||
- 价值来自预测时：确认训练数据和标签口径；缺失价值不得补 0 或平均数，除非用户确认规则。
|
||||
|
||||
### 5.3 停止门
|
||||
|
||||
资源/接收者清单、候选关系、保护/冲突、容量、唯一性、价值口径、竞争关系和公平定义任一未确认，不得执行分配。
|
||||
|
||||
## 6. 场景分支三：绩效规则与目标
|
||||
|
||||
### 6.1 先拆分隐含问题
|
||||
|
||||
用户说“把季度目标分解”时，至少可能包含：
|
||||
|
||||
- 公司总目标本身能否在资源和能力约束下达成；
|
||||
- 如何分到组织、区域、业务单元、团队和个人；
|
||||
- 如何定义保底、目标、挑战值和达成率；
|
||||
- 如何设计奖金/惩罚/封顶等激励规则；
|
||||
- 如何解释差异并评估公平性。
|
||||
|
||||
入口必须先确认本次要交付哪些部分。不得假设用户只想要一个分解数字。
|
||||
|
||||
### 6.2 最小必问
|
||||
|
||||
1. **范围与层级**：哪些组织、区域、业务单元、团队和个人，完整清单和层级关系；新建/关闭/合并组织如何处理。
|
||||
2. **时间与指标**：季度的起止日期，目标指标是收入、GMV、单量、转化还是组合；含税/退款/跨期口径。
|
||||
3. **总目标**：组织/区域总目标是固定硬约束、区间还是待验证的期望；增长 10% 是上限、建议值还是每层都适用。
|
||||
4. **历史基础**：“以前收入”的观察窗口、季节性、异常期、人员/业务单元可比性和归属口径。
|
||||
5. **资源潜力**：资产、机会、市场容量、人员和营销资源如何映射到各层；潜力是历史、预测还是政策值。
|
||||
6. **可达性**：能力上限、保底、挑战值、置信区间和不可达判定；预测值是否允许直接成为上限。
|
||||
7. **公平**：同层比较组、差异来源、允许偏差、是否保护新人/低基数/特殊区域。
|
||||
8. **目标权衡**：增长、历史基础、资源潜力、稳定、公平之间用硬顺序、权重还是 Pareto；权重由谁批准。
|
||||
9. **规则输出**：只分目标还是同时优化奖金档位、达成率、封顶、惩罚与预算；哪些规则不可改。
|
||||
|
||||
### 6.3 条件触发追问
|
||||
|
||||
- 同一区域业务单元争夺相同资源时：确认目标是否应考虑蚕食、共享机会、跨单元结果归属和内部竞争激励。
|
||||
- 资源分配尚未确定时：确认先分资源再定目标，还是联合优化；不得把未来资源默认按历史分布。
|
||||
- 人员流动时：确认在岗天数、转店、离职、新人爬坡和业绩归属。
|
||||
- 低基数高增长时：确认增长率封顶、绝对增量和异常值处理。
|
||||
- 设计奖金规则时：确认预算、档位、边际激励、团队/个人冲突、封顶和反作弊规则。
|
||||
- 总目标可能不可达时：确认只报告缺口/IIS，还是谁有权调整总目标、资源或公平边界。
|
||||
|
||||
### 6.4 停止门
|
||||
|
||||
真实交付范围、组织层级、指标口径、总目标性质、历史基线、资源潜力、竞争关系、可达性、公平比较组和权衡方式任一未确认，不得生成个人或组织目标。
|
||||
|
||||
## 7. 场景分支四：集中任务调度
|
||||
|
||||
### 7.1 最小必问
|
||||
|
||||
1. **真实决策**：当前批次分配、实时滚动调度、优先级排序还是推荐后人工确认。
|
||||
2. **任务**：任务 ID、到达时间、渠道、客户/机会去重键、技能要求、优先级、截止/SLA、预计处理时长、必须服务与可延期标记。
|
||||
3. **人员**：人员 ID、技能/熟练度、在线和班次、休息、并发、在手任务、禁止服务关系。
|
||||
4. **时段**：起止时间、时区、调度粒度、冻结窗口和下一轮滚动时间。
|
||||
5. **SLA**：30 分钟从哪个事件起算，触达/接通/完成哪个节点算达成；不同优先级是否不同。
|
||||
6. **目标**：必须服务、SLA、价值、等待、负载公平的硬顺序或权重。
|
||||
7. **处理时长**：历史/预测/人工规则来源、分位数、缺失和置信度处理。
|
||||
8. **不可覆盖**：允许逾期、留队列、外溢、跨技能支援还是必须报告不可行；成本和权限。
|
||||
|
||||
### 7.2 条件触发追问
|
||||
|
||||
- 同一客户多任务时：确认去重、合并、联系冷却期和多渠道冲突。
|
||||
- 可抢占/重分时：确认已开始任务是否锁定、切换成本、最大重分次数和通知规则。
|
||||
- 多技能人员时：确认技能等级、替代关系、熟练度折损和保留容量。
|
||||
- “高意向”来自模型时：确认标签/阈值/版本、误判成本和更新频率。
|
||||
- 任务有先后依赖时：确认前置完成、批次成组、互斥和同人连续服务要求。
|
||||
- 排班未确定时：确认使用已发布班次，还是与排班联动；不得假设 180 人全程在线。
|
||||
|
||||
### 7.3 停止门
|
||||
|
||||
任务/人员清单、在线时段、技能资格、处理时长、SLA 起止定义、去重冲突、目标优先级和不可覆盖策略任一未确认，不得调度。
|
||||
|
||||
## 8. 场景分支五：服务人员与集中作业排班
|
||||
|
||||
### 8.1 最小必问
|
||||
|
||||
1. **真实决策**：安排班次模板、具体人员排班、技能覆盖，还是只评估未来缺口。
|
||||
2. **需求**：未来日期与每个时段/技能的到达量或所需人数；预测版本、服务水平换算和安全裕量。
|
||||
3. **人员**：员工 ID、合同/角色、技能、可用性、请假、培训、固定班、兼职和有效日期。
|
||||
4. **班次模板**：开始/结束、休息、跨日、可拆分、最短/最长长度和模板适用技能。
|
||||
5. **规则**：日/周工时、休息间隔、连续工作、夜班、周末、法定节假日、资质覆盖；来源和适用人群。
|
||||
6. **目标**：覆盖缺口、人工成本、加班、偏好、公平、稳定的优先级或权重。
|
||||
7. **公平/偏好**：比较群体、夜班/周末/总工时公平口径，偏好是硬限制还是软罚分。
|
||||
8. **缺口策略**：加班、跨技能、临时工、外包、降 SLA 或只报告缺口，谁有权启用。
|
||||
|
||||
### 8.2 条件触发追问
|
||||
|
||||
- 多技能替代时：确认技能矩阵、等级、替代折损、最低在岗人数和关键技能保留。
|
||||
- 预测不确定时：确认使用均值、分位数、情景/鲁棒优化，及允许的缺口风险。
|
||||
- 与任务调度联动时：确认先排班后调度，还是联合模型；处理时长和并发口径必须一致。
|
||||
- 人员有固定承诺时：确认已发布班次、换班、培训、请假和不可更改窗口。
|
||||
- 规则因地区/合同不同：确认每人的规则集合；不得用一套规则覆盖全部人员。
|
||||
- “公平”涉及个人利益时：确认权重、保护组和审批人。
|
||||
|
||||
### 8.3 停止门
|
||||
|
||||
需求口径、人员可用性、班次模板、规则来源、技能替代、目标权衡、公平和缺口策略任一未确认，不得生成排班。
|
||||
|
||||
## 9. 场景分支六：通用 LP/MILP
|
||||
|
||||
### 9.1 最小必问
|
||||
|
||||
1. **真实决策与支持边界**：只判断是否线性可表达、验证可行性，还是交付求解结果；是否接受 LP/MILP 边界。
|
||||
2. **索引集合**：实体、时段、场景、弧/候选关系的完整集合和稳定 ID。
|
||||
3. **决策变量**：业务含义、索引、连续/整数/二进制域、上下界和单位。
|
||||
4. **目标**：最大/最小、各项公式、系数来源、单位、权重/优先级和常数项。
|
||||
5. **约束**：逐条业务规则、索引范围、左右式、方向、界、硬/软、松弛变量和罚分。
|
||||
6. **耦合**：跨实体、跨时间、互斥、成组、先后、容量共享、竞争、替代和守恒关系。
|
||||
7. **数据**：每个系数/界/集合的来源、版本、缺失、精度和未来不确定性。
|
||||
8. **非线性/不确定性**：乘积、比率、分段、逻辑、随机变量和鲁棒要求；是否允许线性化及误差。
|
||||
9. **不可行和验收**：只报告 IIS，还是允许哪些已授权放松；容差、基线和结果核验方式。
|
||||
|
||||
### 9.2 停止门
|
||||
|
||||
变量域、目标系数、约束方向/界、数据来源和不可行策略任一有歧义，不得编译。模型“看起来可线性”不是充分条件。
|
||||
|
||||
## 10. 入口 Agent 的自适应输出协议
|
||||
|
||||
首轮回复必须直接面向用户，使用以下结构，不展示内部推理：
|
||||
|
||||
首轮先按“根据用户了解选择沟通方式”确定 `interaction_state`。不得先调用 `AskUserQuestion` 隐藏覆盖范围；普通文本至少要让用户知道本场景还会核清哪些类别、当前先问什么以及为什么尚不能计算。
|
||||
|
||||
1. **我理解的表面问题**：一句话复述，不宣称已经完整理解。
|
||||
2. **需要先确认的真实决策**：列出 2–4 个可能交付，让用户选择/补充。
|
||||
3. **已确认事实**：仅列 `confirmed_user` / `confirmed_data` / `deterministic_rule`，附来源。
|
||||
4. **请你确认的问题**：专业模式按“范围与对象、目标与基线、硬约束、竞争/耦合、数据、验收”一次公开完整信息契约；业务引导模式先公开上述覆盖类别，再选择当前最连贯、最高影响的一组用白话询问，保留其余项目继续多轮；自适应模式同时询问表达偏好。
|
||||
5. **条件性问题**：使用“如果存在 X，请补充 Y；如果不存在，请明确回复不适用”，不得暗示 X 已存在。
|
||||
6. **固定事实门尾注**：首轮回复必须以下面两句逐字收尾。这是可供人类和程序稳定验收的安全边界，不得同义改写、缩短或合并：
|
||||
|
||||
> 未确认项将保持为缺口；我不会用默认值、模拟情况或行业惯例补全。
|
||||
>
|
||||
> 上述模型影响项确认前，我不会建模、发布建模工件、委派求解或调用求解器。
|
||||
|
||||
问题必须完整但不机械倾倒未命中的分支：只收集当前场景的共享必问、场景必问和已触发条件项。专业模式不设置机械问题数量上限；业务引导模式不设置总轮次上限，也不以固定数字强行切断一个连贯主题。任何分轮都必须维护未问/未确认清单，不能因为用户身份、体验、催促或模式切换而遗漏。
|
||||
|
||||
## 11. 用户回答后的复核协议
|
||||
|
||||
每轮收到回答后：
|
||||
|
||||
1. 更新事实台账，逐项标记 `fact_state` 和来源；
|
||||
2. 明确列出新确认、仍待确认、已确认不适用、相互矛盾四类；
|
||||
3. 若出现新条件，进入对应条件分支继续追问；
|
||||
4. 把任何数值、政策、权重、预测和例外回译给用户确认，尤其是从文件读取但可能口径不明的字段；
|
||||
5. 事实确认门通过时，先给“建模确认摘要”：决策变量、目标、硬/软约束、数据版本、基线、竞争/耦合、不可行策略、验收；用户确认该摘要后才进入求解。
|
||||
|
||||
## 12. 允许和禁止的表述
|
||||
|
||||
允许：
|
||||
|
||||
- “你尚未说明同一区域业务单元是否竞争同一机会；该差异会改变唯一归属和价值计算，请确认竞争/共享/转介中的哪一种适用。”
|
||||
- “如果不存在核心资源保护，请明确回复‘不适用’，我会把它记录为 `not_applicable_confirmed`。”
|
||||
- “下面的 10% 只来自你的原话；它究竟是个人增长上限、各层上限还是建议值，尚未确认。”
|
||||
|
||||
禁止：
|
||||
|
||||
- “通常同一区域业务单元会竞争，因此我先加入竞争约束。”
|
||||
- “未提供历史收入，先按 0/均值/模拟数据求解。”
|
||||
- “默认核心资源固定、其他资产自由分配。”
|
||||
- “为了先跑起来，假设所有 180 名服务人员全程在线。”
|
||||
- “当前系统时区下明日是 `<系统推导日期>`，所以我把 `<系统推导日期>` 记为确定性规则。”
|
||||
Reference in New Issue
Block a user