Agents propose, people decide: how ADIS keeps AI accountable智能体提案，人来决定：ADIS 怎样让 AI 可问责
Reading and drafting run freely. Anything that changes the business waits for a person. Everything is written down. How that one rule becomes a design.查询和起草放手去做；会改变业务的事等人点头；每一步都写下来。这一条规则怎样变成设计。
October 7, 2026 · 4 min read2026 年 10 月 7 日 · 阅读约 3 分钟
Every company that deploys AI agents eventually asks the same question: how much should we let them do?
There are two easy answers, and both are wrong. "Let them do everything" works in a demo and fails the first time an agent changes a price list on its own. "Let them do nothing without a person" is safe and useless: the agent becomes a slower way to fill in forms.
ADIS is built on a third answer, and it fits in one sentence: agents propose, people decide, and everything is written down. This post explains how that sentence turns into design.
Two kinds of work
Most of what a digital employee does all day has no lasting effect on the business. It looks up lead times. It reads a contract and summarises it. It drafts a reply, a comparison sheet, a weekly report. If the draft is wrong, someone fixes the draft. Nothing outside the conversation has changed.
A small part of the work does have a lasting effect: writing a record back into the ERP, sending a letter to a supplier, changing the margin floor in the pricing rules, adding a field to the data model.
So the first design rule is to treat these differently. Reversible work runs freely and is logged. Work that changes the business is a proposal until a person approves it. That single split is what lets an agent be both fast and safe.
One path for change
Rules only hold if there is no way around them. In ADIS, every change to company data goes through an Action: a named, typed operation such as approve quote or record payment, with defined inputs, checks and permissions.
There is no second path. An agent cannot write to the database directly, and it cannot call a business system's API on the side. If something is not an Action, the agent cannot do it to company data. That is what makes the rest of the design enforceable rather than advisory.
Approval is part of the data model
An approval is not a pop-up. It is a record with a proposal, an approver and a decision, and the rules for who may approve live next to the Action itself:
- Who approves is defined by group, not by name, so it survives reorganisations: the procurement manager role approves purchases above a threshold, finance approves payments.
- Money can require four eyes. Monthly partner settlements, for example, are approved by two people, by design rather than by habit.
- Nobody approves their own proposal. An agent can draft, check and submit; approving and merging are done by people. Authorship and approval never sit with the same author.
The same applies one level up. When an agent wants to change the shape of the data itself, for example a new object type or a new rule, it opens a proposal against the ontology, and a person reviews and merges it.
An agent sees what its team sees
Every digital employee has its own identity in the system: a service user that cannot log in and holds no rights of its own. What it may read is granted the same way rights are granted to people, through the groups it belongs to, and then narrowed further by the restrictions on its key.
The result is an intersection, never a union. A procurement agent added to the procurement group reads purchasing data. If it is not in any group, it reads nothing, and the platform answers with a refusal rather than a guess. Sensitive data carries markings that travel with it, so a document marked for finance stays with finance no matter which agent touches it.
Everything is written down
Every Action and approval lands in the Action Log: who did what, on which records, when, and on whose behalf. Answers in chat cite the records they read. File operations, such as who shared or moved a document, are kept in an audit trail.
This is less about catching mistakes after the fact than about making delegation rational. When every step can be traced, a manager can let an agent take on more, because they can always see what it did.
Governance is not what slows AI down. It is what lets a company say yes to it.
Why this makes deployment faster
It is tempting to see approvals as friction. In practice they are the reason a deployment can move quickly.
A finance team will not hand reconciliation to an agent that can post journal entries on its own. It will happily hand it to one that prepares the entries, cites the bank lines it matched and waits for a click. A bank's operations team cannot use an agent whose access is "roughly what the person who set it up could see". It can use one whose access is an auditable intersection of groups and restrictions.
Bounding the risk is what allows the scope to grow. That is why, in every deployment, the first artefact we sign with a customer is not a prompt. It is the list of Actions, who approves each one, and what each agent may read.
每家部署 AI 智能体的公司，迟早都会问同一个问题：该让它们做多少？
有两个省事的答案，都不对。「什么都让它做」在演示里行得通，第一次它自己改了价目表就出事。「没有人在场什么都不让它做」很安全，也没用：智能体成了一个更慢的填表工具。
ADIS 建立在第三个答案上，一句话能说完：**智能体提案，人来决定，每一步都写下来。**这篇讲这句话怎么变成设计。
两类工作
数字员工一天里做的大部分事，对业务没有持久影响。查交期，读合同写摘要，起草回复、比价单、周报。初稿错了，改初稿就行，对话之外什么都没变。
只有一小部分工作有持久影响：把一条记录写回 ERP，给供应商发信，改定价规则里的毛利底线，给数据模型加一个字段。
所以第一条设计规则，是区别对待这两类工作。可以撤回的工作放手去做，留痕；会改变业务的工作，在有人批准之前都只是提案。正是这一刀，让智能体既快又稳。
改动只有一条路
规则只有绕不过去才算数。在 ADIS 里，对公司数据的每一次改动都走动作（Action）：一个有名字、有类型的操作，比如「批准报价」「登记收款」，输入、校验和权限都事先定义好。
没有第二条路。智能体不能直接写数据库，也不能绕到旁边去调业务系统的接口。不是动作，智能体就动不了公司数据。正因如此，后面这些设计才是强制的，而不是建议。
审批是数据模型的一部分
审批不是一个弹窗。它是一条记录：有提案、有审批人、有结论；谁能批，就写在动作旁边：
- 谁来批，按组定义。 不按人名，换岗也不失效：超过阈值的采购由采购经理这个角色批，付款由财务批。
- 钱可以要求两个人。 比如伙伴的月度结算，按设计就要两人批准，而不是靠习惯。
- 没有人能批自己的提案。 智能体可以起草、检查、提交；批准和合并由人来做。作者和审批人永远不是同一个。
再往上一层也一样。智能体想改数据本身的形状，比如加一个对象类型、加一条规则，就对本体开一个提案，由人审阅、合并。
智能体只看得到团队看得到的
每名数字员工在系统里都有自己的身份：一个服务用户，不能登录，本身没有任何权限。它能读什么，和给人授权一样，通过它所在的组授予，再被它的 Key 上的限制进一步收窄。
结果是交集，从来不是并集。加进采购组的采购智能体，能读采购数据；不在任何组里，它什么都读不到，平台直接拒绝，而不是猜。敏感数据带着标记，标记跟着数据走：标给财务的文件，无论哪个智能体经手，都只留在财务。
每一步都写下来
每一个动作、每一次审批，都记进 Action Log：谁、对哪些记录、在什么时候、代表谁做了什么。群里的回答附上它读过的记录。文件操作，比如谁分享了、移动了一份文件，记在审计记录里。
这与其说是为了事后抓错，不如说是让「放手」变得合理。每一步都查得到，管理者才敢让智能体接更多的活，因为随时能看到它做了什么。
让 AI 慢下来的不是治理。治理恰恰是公司敢对它说「好」的原因。
为什么这让部署更快
把审批看成摩擦，很自然。实际上，它是部署能走得快的原因。
财务团队不会把对账交给一个能自己记账的智能体；但会很乐意交给一个先准备好分录、附上它匹配的银行流水、等人点一下的智能体。银行的运营团队用不了一个权限「大概等于当初搭它的那个人」的智能体；但可以用一个权限是「组与限制的交集」、能审计的智能体。
先把风险框住，范围才能放大。所以每次部署，我们和客户签的第一份东西不是提示词，而是动作清单：每个动作谁来批，每个智能体能读什么。
AIDC · AI Deployment CompanyAIDC · AI Deployment Company
